Java classes et méthodes Question

Question

En tant que quelqu'un qui apprend Java à partir de rien, qui connaît un peu Python, je me suis demandé ce que sont avec tous les modificateurs d'accès (public, statique, protégé ...) en Java. Je sais ce qu'ils veulent dire, mais pourquoi les utiliser? C'est juste quelque chose qui m'embête, parce que chaque fois que j'écris une nouvelle classe et que j'écris les variables d'instance que je dois constamment me poser, est-ce que je veux que cette variable soit privée, publique, finale, etc? Je viens généralement à la conclusion que je ne tiens pas compte de la majorité des varibles et des méthodes. Il y a quelques cas où je sais que je devrais appeler la méthode d'une autre classe, mais pourquoi ne pas rendre toutes les méthodes publiques? Est-ce parce que dans de grands projets, vous ne pouvez pas faire confiance à un autre développeur qui ne va pas commencer à fouiller dans votre code?

Answer 1

Utilisez le modificateur de visibilité minimal dans chaque cas. Par exemple, les champs devraient être privés dans presque tous les cas.

Les méthodes peuvent être:

• privée - si elles ne sont utilisées que dans la classe actuelle, comme des aides.
• protégé, si vous souhaitez qu'il soit uniquement accessible aux sous-classes, mais pas aux autres classes. C'est quand vous concevez votre classe pour l'héritage, et vous voulez fournir des crochets pour les sous-classes. package-privé
• - si vous souhaitez utiliser ces méthodes à l'intérieur du même paquet, mais ne veulent pas les exposer au monde extérieur

Elles correspondent toutes à la conception de l'API - quelle fonctionnalité vous voulez que votre API exposer et quoi non. C'est-à-dire quelles méthodes sont internes à votre implémentation, et qui devraient être utilisables par les classes qui utilisent votre classe pour faire leur travail. L'avantage de tout ceci est que vous pouvez changer les méthodes private/package-private sans autre personne que votre propre classe/package en y dépendant. Les rendre publics vous lie à les soutenir. Cela est vrai non seulement lorsque vous concevez une API comme le framework de collections. C'est également vrai lorsque vous concevez votre propre API dans votre propre projet. Les classes doivent être conscientes de beaucoup moins de méthodes (et sont donc plus faciles à changer et à soutenir).

See this presentation par Joshua Bloch sur la conception de l'API (en particulier de 29:00)

Answer 2

Les modificateurs d'accès permettent aux programmeurs de programmer de manière OO et d'utiliser l'encapsulation de données pour écrire des API hermétiques (ou aussi proches que possible).

D'accord, ce n'est pas toujours souhaitable. C'est pourquoi il existe d'autres options.

Answer 3

Il est un concept OO. Tout d'abord, par exemple, "final" est un modificateur qui fera de cette variable une "constante", alors si vous avez besoin d'un constat, vous devez l'utiliser. Lorsque vous commencez à coder des projets réels, vous verrez l'avantage d'avoir ce type d'encapsulation. Ne pas le sous-estimer. Un exemple est lorsque vous coder une méthode qui peut, par exemple, changer à l'avenir.

public void save(Person p){ 
    this.saveInTheDataBase(p); 
} 
private void saveInTheDataBase(Person p){ 
    database.save(p); 
} 
private void saveInFile(Person p){ 
    file.save(p); 
} 

Ensuite, vos clients appellent save(); sans faire attention où il est sauvegardé

Answer 4

Par exemple, il est utile quand vous avez une bibliothèque que vous voulez mettre à jour sans trop changer de code. Les méthodes publiques restent normalement tandis que les méthodes privées peuvent changer.Si l'auteur de la bibliothèque rendait tout public, les utilisateurs de la bibliothèque pourraient utiliser de façon accidentielle de telles méthodes spécifiques à l'implémentation, ce qui rendrait la mise à jour de la bibliothèque plus difficile.

Answer 5

Tout dépend de la quantité de votre API qui est exposée, et donc de ce qui va se casser lorsque vous la modifiez. Code

• private peut être modifié à tout moment que vous aimez et vous savez que vous ne serez affecter votre propre code dans ce seul fichier. Par défaut (paquet privé) vous n'affectez toujours que votre propre code (à l'exception possible de certaines tromperies), mais vous devrez en vérifier davantage.

• protected: le code d'autres personnes peut l'utiliser, mais comme il est limité aux sous-classes, il peut généralement mettre à jour son code assez facilement.

• public code peut être largement utilisé par le code d'autres peuples. Changer ceci peut forcer d'autres personnes à modifier leur code tout au long de leur propre projet. Si vous connaissez d'autres personnes qui utilisent votre code, vous ne devriez probablement pas changer ces méthodes avant d'avoir publié quelques versions marquées @deprecated afin que ces personnes puissent modifier leur code avant de le casser.