Exposer membres dans une structure de données comme classe?

Question

Pour l'utilisation dans une application basée sur les servlets, j'ai écrit une classe pour stocker un nom de vue et des objets à rendre. En fait, il s'agit plus d'une structure de données que d'une classe au sens de la POO. Je me demande si je devrais exposer les membres ou si je devrais utiliser des getters.

public class Result { 

    private final int status; 
    private final String view; 
    private final Map<String, Object> model = new HashMap<String, Object>(); 

    public Result(final int status, final String view) { 
     this.status = status; 
     this.view = view; 
    } 

    public Result put(final String modelName, final Object modelObject) { 
     model.put(modelName, modelObject); 
     return this; 
    } 

} 

Dois-je ajouter getStatus(), getView() et getModel() ou devrais-je changer la visibilité des membres au "public"? À l'heure actuelle, je ne connais aucun scénario où il serait utile d'avoir une méthode pour accéder à un membre. "Résultat" est une structure de données immuable et aucun calcul n'est nécessaire lorsque les membres sont accédés. Souhaitez-vous ajouter des getters pour l'événement improbable que l'implémentation change?

Addendum

J'ai lu une section relative à ma question à Robert C. Martins excellent livre Clean Code (page 99):

Hybrids

Cette confusion [au sujet des objets et les structures de données] conduisent parfois à structures hybrides malheureuses qui sont moitié objet et la moitié st structure. Ils ont des fonctions qui font choses importantes, et ils ont aussi soit des variables publiques ou publiques accesseurs et mutateurs que, pour toutes fins utiles, rendre public la variable privée, tentant autres fonctions externes à utiliser ces les variables la façon dont un programme procédural utiliserait une structure de données. De tels hybrides compliquent l'ajout de nouvelles fonctions , mais compliquent également l'ajout de nouvelles structures de données pour . Ils sont les pire des deux mondes. Évitez de créer eux. Ils sont indicatifs de la conception confuse dont les auteurs ne sont pas sûr de - ou pire, ignorant de - si elles ont besoin de protection contre les fonctions ou types.

Answer 1

Je ne peux pas faire de recommandations concrètes, car cela dépend de la façon dont vous allez utiliser cette classe. Cependant ...

Je crée souvent des objets "légers" destinés à des structures de données pour transporter des données immuables. Comme vous, je crée les membres public final et les initialise dans le constructeur.

Les risques associés aux membres de données accessibles et modifiables ne sont pas présents lorsqu'ils sont définitifs; Tout ce que vous perdez, c'est la capacité de sous-classer la classe de façon significative. En outre, vous ne pouvez pas joindre de fonctionnalité à l'accès aux données. Mais pour un objet de transfert de données léger, vous ne le ferez probablement pas de toute façon.

Answer 2

Pour une classe de détenteurs de données, créer des getters ou non est une question de goût. En fonction de votre description, vous pouvez rendre la visibilité publique ou le package sur l'état et la vue, mais j'ajouterais un getter pour récupérer un modèle par son nom. Bien que la carte soit définitive, son contenu ne l'est pas.

Modifier Je voulais dire quelque chose comme:

public Object get(final String modelName) { 
    return model.get(modelName); 
} 

Il n'y a aucune raison de faire la carte du modèle visible. (Je nommerais la carte "modèles" et utiliserais setModel(name, model) et getModel(name) comme accesseurs.)

Answer 3

Vous dites:

le moment, je ne connais aucun scénario où il serait utile de ont une méthode pour accéder à un membre.

C'est précisément pourquoi je recommanderais l'accès aux données via des getters. Au moment où vous utilisez l'objet pour stocker les objets correspondants dans votre modèle. Cependant, votre modèle pourrait bien changer dans le futur, et pourtant vous pouvez vouloir afficher les données dans la vue de la même manière. Étant donné que, et le mal de tête dans le test du composant de vue d'un MVC, j'implémenterais toujours le mécanisme getter/setter.