Лист за преговор: Gestion des dépendances et stabilité en Java

📋 Plan du Cours

1. Hypothèses sur changement
2. Entités nommées Java
3. Contenance et utilisation
4. Dépendances d'utilisation
5. Dépendances de contenance
6. Encapsulation des données
7. Dépendance aux changements

📖 1. Hypothèses sur changement

🔑 Notions clés & Définitions

Attributs d'une classe : Ce sont les variables qui stockent l’état interne d’une classe. Leur rôle est de représenter les données propres à chaque instance ou à la classe elle-même. Selon le contenu source, ils risquent de changer fréquemment, ce qui peut impacter la stabilité de la conception.

Code des méthodes : Il s’agit de l’ensemble des instructions qui définissent le comportement d’une classe. Le code des méthodes peut évoluer indépendamment des autres éléments, ce qui nécessite une conception flexible pour limiter l’impact des modifications.

Contrat public : C’est l’ensemble des éléments accessibles depuis l’extérieur d’une classe, incluant ses méthodes publiques, propriétés, et comportements attendus. Le contrat doit changer le moins possible pour préserver la stabilité du code, notamment du code client.

Code client : Ce sont les programmes ou modules qui utilisent une classe. Leur volume peut être très important, et ils sont souvent sensibles aux changements dans la classe, notamment dans le contrat public ou dans la structure des attributs.

📝 Points essentiels

Les attributs d'une classe risquent de changer fréquemment, ce qui peut nécessiter une conception qui limite leur impact sur le reste du système. Le code des méthodes d'une classe peut évoluer indépendamment, impliquant que leur modification ne doit pas entraîner de modifications majeures dans la structure globale. Le contrat public doit changer le moins possible afin de préserver la stabilité et la compatibilité avec le code client. En revanche, le code client utilisant une classe peut être très volumineux et sensible aux changements, ce qui impose une gestion prudente des évolutions pour éviter de graves régressions ou refontes.

💡 À retenir

Comprendre que les attributs, le code des méthodes, et le contrat public peuvent changer à des degrés divers guide la conception pour minimiser l’impact sur le code client, en privilégiant la stabilité du contrat public et en anticipant la fréquence des modifications des éléments internes.

📖 2. Entités nommées Java

🔑 Notions clés & Définitions

• Paquetages
  Ensemble organisé de classes, interfaces, records, sous-ensembles regroupés sous un nom commun. Ils structurent le code, facilitent la gestion et évitent les conflits de noms.

• Classes
  Entités qui définissent des objets en Java. Elles regroupent attributs, méthodes, constructeurs et autres membres. La classe sert de modèle pour créer des instances.

• Interfaces
  Contrats qui déclarent des méthodes sans en fournir l’implémentation. Elles définissent un comportement que les classes peuvent implémenter pour garantir une certaine compatibilité.

• Records
  Types de données immuables introduits pour représenter des données simples. Ils regroupent des attributs et génèrent automatiquement méthodes comme les getters, equals, hashCode, toString.

• Méthodes
  Actions ou comportements définis dans une classe ou une interface. Elles peuvent prendre des paramètres et retourner une valeur. Elles constituent le point d’interaction avec l’objet ou la classe.

• Constructeurs
  Méthodes spéciales utilisées pour initialiser de nouvelles instances d’une classe. Ils portent le même nom que la classe et n’ont pas de type de retour.

📝 Points essentiels

Les entités nommées en Java incluent les paquetages, classes, interfaces, records, méthodes et constructeurs. Les attributs, variables et paramètres sont aussi des entités nommées mais à un niveau plus local. La nomenclature Java structure le code et facilite la compréhension des dépendances, en permettant d’identifier clairement les rôles et interactions entre ces entités.

💡 À retenir

Identifier précisément les entités nommées en Java, telles que paquetages, classes, interfaces, records, méthodes et constructeurs, est essentiel pour analyser la structure du code, ses dépendances et sa maintenabilité.

📖 3. Contenance et utilisation

🔑 Notions clés & Définitions

Contenance
La contenance d'une entité désigne l'ensemble des éléments ou sous-éléments qui sont inclus ou intégrés dans cette entité. Elle correspond à ce que l'entité "contient" au sens strict, c’est-à-dire ses attributs, ses sous-classes ou ses composants. La définition de ces éléments est incluse dans l’entité elle-même. Par exemple, une classe qui possède des attributs ou des méthodes spécifiques a une contenance qui inclut ces éléments.

Utilisation
L’utilisation d'une entité par une autre se produit lorsque cette dernière fait référence au nom de l’entité sans que cette dernière ne soit définie à l’intérieur. Autrement dit, une entité A utilise une entité B si A mentionne B dans son contenu, mais ne contient pas B dans sa définition. Par exemple, une classe qui déclare un type d’attribut ou une variable de type B utilise B sans le définir.

Définition incluse
Une entité A contient B si la définition de B est incluse dans A. Cela signifie que B fait partie intégrante de A, comme un attribut ou une sous-classe définie dans A.

Nom apparaissant
Une entité A utilise B si le nom de B apparaît dans A sans que B soit défini dans A. Cela indique une dépendance ou une référence à B, sans que B fasse partie intégrante de la définition de A.

📝 Points essentiels

Une entité A contient B si la définition de B est incluse dans A. Par exemple, une classe qui possède des attributs ou des sous-classes définit B comme étant contenu dans A.
Une entité A utilise B si le nom de B apparaît dans A sans que B soit défini dans A. Par exemple, une classe qui déclare un attribut de type B ou qui référence B dans ses méthodes utilise B sans le contenir.
Il est crucial de distinguer la contenance de l’utilisation pour analyser précisément les relations et dépendances. La contenance concerne ce qui est intégré dans l’entité, tandis que l’utilisation concerne ce à quoi l’entité fait référence sans l’intégrer.
Une compréhension fine de cette distinction permet d’analyser efficacement la structure et la dépendance entre différentes entités dans le code, facilitant la maintenance et l’évolution.

💡 À retenir

Différencier clairement la contenance et l’utilisation permet d’analyser finement les relations et dépendances dans le code, ce qui est essentiel pour une compréhension précise de la structure et pour gérer efficacement les changements.

📖 4. Dépendances d'utilisation

🔑 Notions clés & Définitions

Graphe de dépendances
AUTEUR (date) : outil permettant de représenter graphiquement les relations de dépendance entre différentes entités du code, notamment en indiquant qui utilise quoi et dans quel sens.

Utilisations dans commentaires
Les utilisations dans les commentaires désignent les références ou mentions explicites de classes, méthodes ou variables dans les commentaires ou chaînes de caractères du code, qui peuvent indiquer une dépendance d’utilisation.

Sens de la dépendance
Le sens de la dépendance est crucial : il indique la direction dans laquelle la dépendance doit être respectée. Souvent, A ne doit pas utiliser B alors que l'inverse est possible, ce qui influence la conception pour éviter des couplages indésirables.

📝 Points essentiels

Les outils peuvent générer des graphes de dépendances d'utilisation dans le code Java, permettant d'identifier visuellement les relations entre classes, méthodes ou autres éléments. Ces graphes ne se limitent pas aux dépendances explicites dans le code, mais incluent aussi celles présentes dans les commentaires et chaînes de caractères, ce qui offre une vision plus complète des interactions.

Le sens de la dépendance est une notion essentielle : il faut analyser dans quelle direction la dépendance doit être orientée. Il est souvent souhaitable que A ne dépende pas de B si cela introduit un couplage indésirable, surtout si c’est B qui pourrait dépendre de A ou si la dépendance va à l’encontre de la logique de conception. Comprendre et respecter ce sens permet d’éviter des dépendances inverses ou inutiles, favorisant une architecture plus flexible et maintenable.

💡 À retenir

Analyser les dépendances d'utilisation en portant une attention particulière au sens de la dépendance est essentiel pour éviter des couplages indésirables dans le code, ce qui contribue à une conception plus claire, modulaire et évolutive.

📖 5. Dépendances de contenance

🔑 Notions clés & Définitions

• AUTEUR : voir section 4

• Raison de changer : AUTEUR (date) : principe selon lequel chaque entité doit avoir une seule raison de modification. Cela permet de simplifier la gestion des évolutions en limitant l’impact des changements à une seule cause identifiable.

• Isolation des éléments changeants : AUTEUR (date) : stratégie consistant à séparer et encapsuler les éléments susceptibles de changer, afin de réduire leur influence sur le reste du système. Cela facilite la maintenance et l’évolution en limitant les dépendances.

📝 Points essentiels

• Chaque entité doit avoir un seul rôle ou préoccupation pour rester cohérente, ce qui évite la surcharge fonctionnelle et facilite la compréhension du code.

• Une entité doit avoir une seule raison de changer, ce qui simplifie la maintenance en permettant de localiser rapidement l’origine d’un changement et d’éviter des modifications multiples et imprévues.

• Quand on sait qu’un élément va changer, il faut l’isoler pour limiter l’impact. Cela consiste à encapsuler ou séparer cet élément afin que les modifications n’affectent pas le reste du système, réduisant ainsi la fragilité et la complexité du code.

💡 À retenir

Maintenir la cohérence d’entité et isoler les éléments sujets à changement permet de réduire les dépendances et de faciliter l’évolution du système.

📖 6. Encapsulation des données

🔑 Notions clés & Définitions

• Cacher les données : La pratique consistant à rendre les attributs d'une classe inaccessibles directement depuis l'extérieur, afin de limiter les dépendances entre classes. Cela permet de contrôler l'accès et la modification des données internes.
• Limiter les dépendances : Réduire le couplage entre différentes classes en évitant que le code client dépende directement des détails d'implémentation ou des attributs internes, favorisant ainsi la stabilité et la flexibilité du code.
• Simplifier le code client : Rendre le code qui utilise la classe plus clair et plus facile à maintenir en masquant la complexité et en fournissant une interface simple pour accéder aux données.
• Getter comme abstraction : Utiliser des méthodes d'accès (getters) pour fournir une interface stable pour accéder aux données internes, plutôt que d'exposer directement les attributs, permettant ainsi de changer l'implémentation sans impacter le code client.

📝 Points essentiels

Les données d'une classe doivent être cachées aux autres classes pour limiter les dépendances, ce qui évite que le code client dépende directement des détails internes. Cette encapsulation facilite également le changement des données internes sans impact sur le reste du programme, car le code client interagit uniquement via des méthodes d'abstraction comme les getters. En utilisant ces getters, le code devient plus clair et simple, car il ne manipule pas directement les attributs, mais interagit avec une interface stable. Cela permet également de dépendre d'une abstraction plutôt que des attributs concrets, renforçant la robustesse et la stabilité du code.

💡 À retenir

L'encapsulation protège les données internes en les rendant inaccessibles directement, tout en stabilisant l'interface d'accès grâce aux getters, ce qui contribue à un code plus robuste, évolutif et moins dépendant des détails d'implémentation.

📖 7. Dépendance aux changements

🔑 Notions clés & Définitions

Propagation des changements

• AUTEUR : voir section 4

Dépendance à l'abstraction
AUTEUR (date) : dépendance d’un client à une interface ou une abstraction plutôt qu’à une classe concrète, permettant ainsi de réduire l’impact des changements et d’accroître la flexibilité.

Polymorphisme
AUTEUR (date) : capacité d’interchanger différentes implémentations d’une même interface ou classe abstraite sans modifier le code client, facilitant l’extension et la maintenance.

Injection de dépendances
AUTEUR (date) : technique consistant à fournir à une classe ses dépendances (objets) déjà créés, plutôt que de laisser la classe les instancier elle-même, ce qui diminue le couplage.

📝 Points essentiels

Les changements dans une classe se propagent vers le code client si celui-ci dépend des détails concrets de cette classe. Par exemple, une dépendance forte au type précis d’un objet oblige à modifier le code client à chaque évolution de la classe concrète. À l’inverse, en dépendant uniquement d’une abstraction (interface), le code client reste inchangé même si l’implémentation concrète évolue.

Il est crucial de dépendre d’abstractions stables (interfaces) plutôt que des classes concrètes. Cela permet d’interchanger facilement les implémentations sans modifier le code client, ce qui limite la propagation des changements.

Le polymorphisme joue un rôle clé en permettant d’interchanger des implémentations différentes d’une même interface sans toucher au code client. Par exemple, l’ajout d’une nouvelle classe LivraisonExpress implémentant Livraison ne nécessite pas de modification du code existant, grâce à cette capacité d’interchanger les implémentations.

L’injection de dépendances, en fournissant à une classe ses objets dépendants déjà créés, évite que cette classe crée elle-même ses dépendances. Cela réduit le couplage, facilite la substitution des implémentations, et limite la propagation des changements.

💡 À retenir

Réduire la dépendance aux détails concrets en utilisant des abstractions et le polymorphisme permet de minimiser l’impact des changements sur le code client, assurant ainsi une meilleure maintenabilité et évolutivité.

📊 Tableaux de Synthèse

Élément	Définition	Rôle / Fonction	Auteur / Référence
Attributs d'une classe	Variables stockant l’état interne d’une classe	Représentent les données propres à chaque instance ou à la classe elle-même	—
Code des méthodes	Instructions définissant le comportement d’une classe	Évoluer indépendamment, nécessitant une conception flexible	—
Contrat public	Ensemble des éléments accessibles depuis l’extérieur (méthodes, propriétés)	Garantir la stabilité et la compatibilité avec le code client	—
Entités nommées Java	Classes, interfaces, records, méthodes, constructeurs	Structurer le code, analyser dépendances et maintenabilité	—
Contenance	Ensemble d’éléments inclus dans une entité (attributs, sous-classes)	Définir ce que l’entité contient	—
Utilisation	Référence à une entité sans en faire partie	Dépendance ou référence externe	—
Graphe de dépendances	Représentation graphique des relations de dépendance	Visualiser qui utilise quoi dans le code	—

⚠️ Pièges & Confusions Fréquentes

1. Confondre contenance et utilisation : penser qu’un nom apparaissant dans une classe signifie qu’elle la contient alors qu’elle peut simplement la référencer.
2. Sous-estimer la fréquence des changements dans les attributs versus le code des méthodes ou le contrat public.
3. Croire que le contrat public doit évoluer fréquemment ; il doit au contraire rester stable pour préserver la compatibilité.
4. Négliger l’impact des modifications internes sur le code client, surtout si celui-ci est volumineux.
5. Ignorer que les records sont immuables, ce qui limite leur modification mais simplifie leur gestion.
6. Confondre classes et interfaces : une interface ne contient pas d’implémentation concrète.
7. Omettre de considérer la direction du sens de dépendance dans le graphe pour éviter un couplage indésirable.

✅ Checklist Examen

• Connaître la définition de PERROUX sur la croissance et sa relation avec la stabilité du système.
• Savoir distinguer entre attributs, code des méthodes, et contrat public d’une classe.
• Identifier les différentes entités nommées en Java : classes, interfaces, records, méthodes, constructeurs.
• Expliquer ce qu’est la contenance d’une entité et comment elle diffère de l’utilisation.
• Savoir représenter graphiquement un graphe de dépendances et interpréter ses relations.
• Comprendre l’impact potentiel des changements internes sur le code client.
• Maîtriser la notion de stabilité du contrat public pour limiter les régressions.
• Reconnaître un record et ses caractéristiques d’immuabilité.
• Analyser une déclaration pour déterminer si une entité utilise ou contient une autre.
• Identifier les faux amis ou pièges courants liés à la terminologie Java (ex : classe vs interface).
• Connaître l’importance du sens de dépendance dans la conception orientée objet.
• Vérifier la maîtrise du concept de graphe de dépendances et sa lecture.