Je suis entièrement d'accord avec Konamiman de la réponse, mais je voudrais ajouter une chose:
Il ya des cas où vous ne voulez vraiment pas que l'abstraction. Et c'est bien.
Un simple exemple, je tiens à utiliser ici est une classe pour un 3-dimensions du flotteur vecteur:
class Vector3f {
public:
float x;
float y;
float z;
};
Pourriez-vous faire de ces domaines privé et de fournir des setters à la place? Bien sûr, vous pourriez. Mais ici, vous pourriez dire que la classe est vraiment juste censé fournir un n-uplet de flotteurs et vous ne voulez pas de fonctionnalités supplémentaires. Ainsi, l'ajout de setters ne ferait que compliquer la classe et vous préférez laisser le champs public.
Maintenant, vous pouvez facilement construire des scénarios où cela pourrait vous mordre plus tard. Par exemple, vous pourriez obtenir un jour une exigence qu' Vector3f
s ne sont pas autorisés à stocker NaN
s et doit lever une exception si quelqu'un essaie de le faire. Mais tel un futur hypothétique problème ne devrait pas être suffisant pour justifier l'introduction de nouvelles abstractions.
C'est votre appel en tant que programmeur pour décider qui des abstractions faire sens pour le problème à la main et ceux qui ne ferait que nuire à votre façon de faire le travail. Inutile abstractions sont sur-l'ingénierie et va nuire à votre productivité, tout autant que de ne pas abstraire suffisamment.
Bas de ligne: Ne pas aveuglément l'utilisation poseurs de partout juste parce que quelqu'un a prétendu que c'est bien pratique. Au lieu de cela, penser le problème à portée de main et d'envisager les avantages et les inconvénients.