Surtout pour le début des cours dans le nouveau volet du cours "Architecture et Design Patterns", j'ai préparé un autre matériel d'auteur.
introduction
Lorsqu'il s'agit de modèles de conception classiques, on ne peut s'empêcher de penser à la programmation orientée objet elle-même. Après tout, les modèles GoF sont exactement des modèles de programmation orientés objet. La programmation fonctionnelle a ses propres modèles.
En général, tout est organisé comme suit: il y a la programmation orientée objet elle-même. Il a des principes. À partir des principes de la programmation orientée objet, les modèles GRASP que nous avons analysés suivent (en option - principes SOLID), à partir desquels, à leur tour, les modèles GoF suivent. Un certain nombre de choses intéressantes en découlent, par exemple, les modèles d'entreprise.
Paradigme orienté objet
La définition déclare que «la programmation orientée objet est un paradigme de programmation dans lequel le concept de base est la notion d'objet qui est identifié au domaine».
Ainsi, le système est représenté comme un ensemble d'objets du domaine, qui interagissent les uns avec les autres d'une manière ou d'une autre. Chaque objet a trois composants: identité, état et comportement.
L'état d'un objet est une collection de tous ses champs et de leurs valeurs.
Le comportement d'un objet est la collection de toutes les méthodes de la classe d'un objet.
L'identité d'objet est ce qui distingue un objet de classe d'un autre objet de classe. Du point de vue Java, c'est par identité que la méthode equals est définie.
Principes de programmation orientée objet
La programmation orientée objet a un certain nombre de principes. L'idée de leur nombre diffère. Quelqu'un prétend qu'il y en a trois (ancienne école de programmeurs), quelqu'un prétend qu'il y en a quatre (nouvelle école de programmeurs):
- Abstraction
- Encapsulation
- Héritage
- Polymorphisme
Je propose d'en parler plus en détail. La seule chose est que je suggère de ne pas considérer l'abstraction, car je me considère comme étant dans la vieille école des programmeurs.
Encapsulation
Contrairement à l'opinion de nombreuses personnes interrogées (et parfois des personnes interrogées), l'encapsulation n'est pas «lorsque tous les champs sont privés». L'encapsulation est le principe le plus fondamental de la conception logicielle, ses traces ne sont observées qu'au niveau micro, mais aussi au niveau macro-design.
La définition scientifique dit que "l'encapsulation est le principe selon lequel toute classe et, dans un sens plus large, toute partie du système doit être considérée comme une" boîte noire ": l'utilisateur d'une classe ou d'un sous-système ne doit voir que l'interface (c'est-à-dire une liste de propriétés et de méthodes déclarées ) et ne pas se plonger dans la mise en œuvre interne. "
Ainsi, il s'avère que si la classe A fait directement référence aux champs de la classe B, cela ne conduit pas au fait que "la sécurité de l'information est violée", mais au fait que la classe A est liée au périphérique interne de la classe B, et à une tentative de changer la structure interne de la classe B conduira au changement de classe A. De plus, la classe A ne fonctionne pas seulement avec les champs de la classe B, elle fonctionne selon une logique métier. Autrement dit, la logique pour travailler avec l'état de la classe B réside dans la classe A, et lorsque nous voulons réutiliser la classe B, cela ne peut pas être fait, car sans un morceau de classe A, la classe B peut être inutile, ce qui conduira au fait que la classe B devra être donnée avec classe A. En extrapolant cela à l'ensemble du système, il s'avère que seul le système entier peut être réutilisé.
L'encapsulation est le principe le plus négligé et, malheureusement, peu de gens interprètent correctement. Il vous permet de minimiser le nombre de liens entre les classes et les sous-systèmes et, par conséquent, de simplifier l'implémentation et la modification indépendantes des classes et des sous-systèmes.
Héritage
L'héritage est la capacité de dériver une classe d'une autre tout en préservant toutes les propriétés et méthodes de la classe ancêtre (superclasse), en ajoutant de nouvelles propriétés et
méthodes si nécessaire .
L'héritage est le principe le plus surfait. On croyait autrefois que "pour un programmeur idéal, l'arbre d'héritage va à l'infini et se termine par un objet absolument vide", car une fois que les gens ne comprenaient pas très bien que l'héritage est un moyen d'exprimer une propriété du monde réel sous forme de hiérarchie, et non un moyen réutiliser le code en héritant de la machine du réfrigérateur, car les deux éléments ont une poignée. Il est souhaitable d'éviter l'héritage autant que possible, car l'héritage est une relation très forte. Pour réduire le nombre de niveaux d'héritage, il est recommandé de construire une arborescence «ascendante».
Polymorphisme
Le polymorphisme est la possibilité d'utiliser des classes descendantes dans un contexte destiné à la classe ancêtre.
Derrière la définition la plus sadique se cache la capacité du langage de programmation à décomposer une tâche et à refactoriser les if et les commutateurs.
