Quelle devrait être l'accessibilité des champs dans une classe abstraite?

Question

Pour le mettre simplement à titre d'exemple,

public abstract class AbstractFellow { 

    protected Thing buddy; 
.... 

public class ConcreteFellow extends AbstractFellow { 
    public void someMethod() { 
      buddy.doSomething(); 
      //OR 
      buddy = somethingElse; 
      //OR 
      somethingElse = buddy; 
    } 
} 

Est-ce une mauvaise pratique?

Answer 1

Les opinions varient. Mon opinion est que même dans les classes abstraites, l'utilisation de membres privés et d'accesseurs protégés (c'est-à-dire protected getBuddy()) est une meilleure pratique.

Il permet la même chose que l'encapsulation toujours autorisée: contenir la logique d'obtention de l'objet "buddy" dans la super-classe, et vous permettre de changer cette logique sans casser toutes les classes héritées.

La superclasse peut ne pas s'attendre à ce que buddy soit modifiée. Par exemple, vous pouvez désinscrire les écouteurs ou effectuer un autre nettoyage lorsque cela se produit. Une méthode setter permet d'y parvenir. De plus, cela vous permet évidemment d'avoir Buddy en tant que membre en lecture seule (puisque vous ne pouvez fournir qu'un getBuddy et aucun setBuddy), quelque chose qui n'est pas aussi facile à accomplir avec un membre (vous pouvez toujours le définir

Answer 2

Cela dépend de votre modèle de domaine et de la raison pour laquelle vous avez créé et résumé des classes. Si vous définissez votre interface avec elle et que vous souhaitez que la classe abstraite conserve certaines fonctionnalités, c'est OK.

Si vous définissez simplement tous les champs protégés et réutilisez-les dans vos classes enfants. Ça dépend, mais je pense qu'il faudrait trouver un meilleur moyen. Et il ne semble pas très clair pour votre futur lecteur d'obtenir des données dans la classe de base et tout son comportement dans les classes enfant. Si vous n'avez pas besoin de la capacité de la classe de base pour implémenter des méthodes (et que vous n'avez besoin de stocker aucune fonctionnalité dans votre classe de base), il est peut-être préférable d'implémenter une interface avec chacune de ces classes enfants.

Si vous utilisez des champs internes de classe de base, cela me semble naturel et c'est correct. Juste si vous utilisez certains d'entre eux dans vos classes enfant pour des choses similaires, vous pouvez implémenter une méthode de gabarit et en profiter en ne remplaçant que les parties que vous avez vraiment besoin de remplacer.