Pourquoi l'encapsulation est une caractéristique importante des langues OOP?
Je suis tombé sur une interview différente où la question m'a été posée pourquoi l'encapsulation est utilisée? À qui appartient réellement l'encapsulation? Est-ce pour les utilisateurs du programme? Ou est-ce pour les collègues? Ou est-ce pour protéger le code contre les pirates?
L'encapsulation permet d'isoler les détails d'implémentation du comportement exposé aux clients d'une classe (autres classes/fonctions qui utilisent cette classe) et vous donne plus de contrôle sur le couplage dans votre code. Considérez cet exemple, similaire à celui du livre de Robert Martin Clean Code :
public class Car
{
//...
public float GetFuelPercentage() { /* ... */ };
//...
private float gasoline;
//...
}
Notez que le client utilisant la fonction qui vous donne la quantité de carburant dans la voiture ne se soucie pas du type de carburant utilisé par la voiture. Cette abstraction sépare la préoccupation (quantité de carburant) d'un détail sans importance (dans ce contexte): qu'il s'agisse de gaz, de pétrole ou de toute autre chose.
La deuxième chose est que l'auteur de la classe est libre de faire tout ce qu'il veut avec les internes de la classe, par exemple changer l'essence en huile, et d'autres choses, tant qu'ils ne changent pas son comportement. C'est grâce au fait qu'ils peuvent être sûrs que personne ne dépend de ces détails, car ils sont privés. Moins il y a de dépendances dans le code, plus il est flexible et facile à maintenir.
Une autre chose, correctement notée dans la réponse sous-estimée par tnapistim : un couplage faible aide également à tester le code et à maintenir ces tests. L'interface de la classe la moins compliquée est la plus facile à tester. Sans encapsulation, avec tout exposé, il serait difficile de comprendre quoi tester et comment.
Pour réitérer quelques discussions dans les commentaires:
Non, l'encapsulation n'est pas la chose la plus importante dans la POO. J'ose même dire que ce n'est pas très important. Les choses importantes sont encouragées par l'encapsulation - comme un couplage lâche. Mais ce n'est pas essentiel - un développeur prudent peut maintenir un couplage lâche sans encapsuler les variables etc. Comme indiqué par vlastach , Python est un bon exemple de langage qui ne dispose pas de mécanismes pour appliquer l'encapsulation, mais il est toujours possible pour la POO.
Non, masquer vos champs derrière des accesseurs n'est pas de l'encapsulation . Si la seule chose que vous avez faite est d'écrire "privé" devant les variables et ensuite de fournir sans réfléchir la paire get/set pour chacune d'entre elles, alors en fait elles ne sont pas encapsulées. Quelqu'un dans un endroit éloigné du code peut toujours se mêler des internes de votre classe et peut toujours dépendre d'eux (enfin, c'est bien sûr un peu mieux qu'ils dépendent d'une méthode, pas d'un champ).
Non, l'objectif principal de l'encapsulation n'est pas d'éviter les erreurs. Les objectifs principaux sont au moins similaires à ceux énumérés ci-dessus, et penser que l'encapsulation vous défendra de faire des erreurs est naïf. Il existe de nombreuses autres façons de faire une erreur en plus de modifier une variable privée. Et modifier une variable privée n'est pas si difficile à trouver et à corriger. Encore une fois - Python est un bon exemple pour cet argument, car il peut avoir une encapsulation sans l'appliquer.
L'encapsulation empêche les personnes qui travaillent sur votre code de faire des erreurs, en s'assurant qu'elles n'accèdent qu'aux éléments auxquels elles sont censées accéder.
Au moins dans la plupart des langues OO, l'encapsulation est à peu près équivalente à la serrure sur la porte d'une salle de bain.
C'est pas destiné à empêcher quiconque d'entrer s'il veut vraiment entrer.
Il est destiné à être une courtoisie pour faire savoir aux gens que l'entrée entraînera principalement:
- embarras, et
- un désordre puant.
L'encapsulation vous permet de formaliser vos interfaces, en séparant les niveaux d'abstraction (c'est-à-dire "la logique d'application accède IO code uniquement de cette manière et de cette manière")).
Ceci, à son tour, vous permet de modifier l'implémentation d'un module (les données et les algorithmes à l'intérieur du module) sans changer l'interface (et sans affecter le code client).
Cette capacité à modifier les modules indépendamment les uns des autres, améliore votre capacité à mesurer vos performances et à faire des prévisions dans les délais d'un projet.
Il vous permet également de tester des modules séparément et de les réutiliser dans d'autres projets (car l'encapsulation réduit également les interdépendances et améliore la modularité de votre code).
Le non-respect de l'encapsulation a tendance à conduire à l'échec d'un projet (le problème croît avec la complexité du projet).
J'ai conçu un projet accéléré. L'encapsulation réduit la propagation du changement à travers le système. Les changements coûtent du temps et de l'argent.
Lorsque le code n'est pas encapsulé, une personne doit rechercher de nombreux fichiers pour trouver où effectuer les modifications. A l'opposé, il y a la question "Ai-je trouvé tous les endroits?" et l'autre point "quel effet sur l'ensemble du système de faire tous ces changements de dispersion ont?"
Je travaille sur un appareil médical embarqué et la qualité est impérative. De plus, toutes les modifications doivent être documentées, examinées, testées en unité et enfin un test système doit être effectué. En utilisant l'encapsulation, nous pouvons réduire le nombre de modifications et leur localité, ce qui réduit le nombre de fichiers qui doivent être retestés.