8.1 La décomposition est tout
Pour plus de clarté, une image tirée d'un bon article "Decoupling of Object-Oriented Systems", illustrant les principaux points qui seront abordés.
Pensez-vous toujours que concevoir une architecture d'application est facile ?
8.2 Interfaces, masquage d'implémentation
Les grands principes pour réduire le couplage du système sont les principes de la POO et le principe d'Encapsulation + Abstraction + Polymorphisme derrière eux.
C'est pourquoi:
- Les modules doivent être des "boîtes noires" les uns pour les autres (encapsulation) . Cela signifie qu'un module ne doit pas "grimper" dans un autre module et ne rien savoir de sa structure interne. Les objets d'un sous-système ne doivent pas accéder directement aux objets d'un autre sous-système.
- Les modules/sous-systèmes doivent interagir les uns avec les autres uniquement via des interfaces (c'est-à-dire des abstractions qui ne dépendent pas des détails de mise en œuvre). En conséquence, chaque module doit avoir une interface ou des interfaces bien définies pour interagir avec d'autres modules.
Le principe de "boîte noire" (encapsulation) permet de considérer la structure de chaque sous-système indépendamment des autres sous-systèmes. Le module, qui est une "boîte noire", peut être changé relativement librement. Les problèmes ne peuvent survenir qu'à la jonction de différents modules (ou d'un module et d'un environnement).
Et cette interaction doit être décrite sous la forme la plus générale (abstraite), c'est-à-dire sous la forme d'une interface. Dans ce cas, le code fonctionnera de la même manière avec toute implémentation conforme au contrat d'interface. C'est cette capacité à travailler avec différentes implémentations (modules ou objets) à travers une interface unifiée qui s'appelle le polymorphisme.
C'est pourquoi Servlet est une interface : le conteneur web ne sait rien des servlets, pour lui ce sont des objets qui implémentent l'interface Servlet et c'est tout. Les servlets connaissent également un peu la structure du conteneur. L'interface Servlet est ce contrat, ce standard, cette interaction minimale nécessaire pour que les applications Web Java dominent le monde.
Le polymorphisme n'est pas du tout le dépassement des méthodes, comme on le croit parfois à tort, mais d'abord l'interchangeabilité des modules/objets avec la même interface ou « une interface, plusieurs implémentations ». Pour implémenter le polymorphisme, le mécanisme d'héritage n'est pas du tout nécessaire. Ceci est important à comprendre car l'héritage en général doit être évité dans la mesure du possible .
Grâce aux interfaces et au polymorphisme, c'est précisément la possibilité de modifier et d'étendre le code sans changer ce qui est déjà écrit (Principe Ouvert-Fermé) qui est obtenue.
Tant que l'interaction des modules est décrite exclusivement sous la forme d'interfaces et n'est pas liée à des implémentations spécifiques, vous avez la possibilité de remplacer absolument "sans douleur" pour le système un module par un autre qui implémente la même interface, ainsi que ajoutez-en un nouveau et élargissez ainsi les fonctionnalités.
C'est comme dans le constructeur LEGO - l'interface normalise l'interaction et sert comme une sorte de connecteur où n'importe quel module avec un connecteur approprié peut être connecté.
La flexibilité du concepteur est assurée par le fait que l'on peut simplement remplacer un module ou une pièce par un autre avec les mêmes connecteurs (avec la même interface), ainsi qu'ajouter autant de nouvelles pièces que l'on veut (en même temps, des les pièces ne sont pas modifiées ou altérées de quelque manière que ce soit).
Les interfaces vous permettent de construire un système plus simple, en considérant chaque sous-système dans son ensemble et en ignorant sa structure interne. Ils permettent aux modules d'interagir et en même temps de ne rien savoir de la structure interne les uns des autres, mettant ainsi pleinement en œuvre le principe de connaissance minimale, qui est à la base du couplage lâche.
Plus les interfaces sont définies de manière générale/abstraite et moins elles imposent de restrictions à l'interaction, plus le système est flexible. À partir de là, un autre des principes de SOLID suit en fait - le principe de ségrégation d'interface , qui s'oppose aux "interfaces épaisses".
Il dit que les interfaces volumineuses et volumineuses doivent être décomposées en interfaces plus petites et plus spécifiques, afin que les clients des petites interfaces (modules dépendants) ne connaissent que les méthodes avec lesquelles ils doivent travailler.
Ce principe est formulé comme suit : « Les clients ne doivent pas dépendre de méthodes (être conscients des méthodes) qu'ils n'utilisent pas » ou « Plusieurs interfaces spécialisées valent mieux qu'une seule universelle ».
Il s'avère qu'une connectivité faible n'est fournie que lorsque l'interaction et les dépendances des modules ne sont décrites qu'à l'aide d'interfaces, c'est-à-dire d'abstractions, sans utiliser de connaissances sur leur structure interne et leur structure.Et en fait, l'encapsulation est ainsi implémentée. De plus, nous avons la possibilité d'étendre / modifier le comportement du système en ajoutant et en utilisant différentes implémentations, c'est-à-dire en raison du polymorphisme. Oui, nous sommes revenus à OOP - Encapsulation, Abstraction, Polymorphism.
8.3 Façade : interface module
Ici un programmeur expérimenté se demandera : si la conception n'est pas au niveau des objets qui implémentent eux-mêmes les interfaces correspondantes, mais au niveau des modules, alors quelle est l'implémentation de l'interface du module ?
Réponse : parlant dans le langage des modèles de conception, un objet spécial peut être responsable de la mise en œuvre de l'interface du module - Façade . Si vous appelez des méthodes sur un objet qui contient le suffixe Gateway (par exemple, MobileApiGateway), il s'agit très probablement d'une façade.
Une façade est un objet d'interface qui accumule un ensemble d'opérations de haut niveau pour travailler avec un certain sous-système, cachant sa structure interne et sa véritable complexité derrière lui . Fournit une protection contre les modifications de l'implémentation du sous-système. Sert de point d'entrée unique - "vous donnez un coup de pied à la façade, et il sait qui doit être viré dans ce sous-système pour obtenir ce dont il a besoin."
Vous venez de découvrir l'un des modèles de conception les plus importants qui vous permet d'utiliser le concept d'interfaces lors de la conception de modules et ainsi de les découpler - "Façade".
De plus, "Facade" permet de travailler avec des modules de la même manière qu'avec des objets ordinaires et d'appliquer tous les principes et techniques utiles qui sont utilisés dans la conception des classes lors de la conception des modules.
Note : Bien que la plupart des programmeurs comprennent l'importance des interfaces lors de la conception de classes (objets), il semble que beaucoup découvrent l'idée d'utiliser également des interfaces au niveau du module.