1. Historique de l'entreprise
Je veux vous raconter une histoire qui montre comment la POO aide à lutter contre la complexité des grands systèmes. Ceci est nécessaire pour que vous compreniez le but de la POO .
Il était une fois une petite entreprise qui fournissait des services de transport intergalactique...
Appelons-le Galaxy Rush. Elle employait 5 personnes. L'un travaillait dans la finance, le deuxième travaillait dans un entrepôt, le troisième faisait les livraisons, le quatrième s'occupait de la publicité et le cinquième gérait toute l'entreprise.
Ils travaillaient très dur et réussissaient à tout. L'entreprise avait une bonne réputation et gagnait beaucoup d'argent. Mais chaque année, il y avait de plus en plus de commandes, le patron a donc dû embaucher des employés supplémentaires. Plusieurs autres pour l'entrepôt, plusieurs autres pour les livraisons, un de plus pour les finances et un expert en publicité supplémentaire pour élargir la part de marché de l'entreprise.
Et c'est là que les problèmes ont commencé. Il y avait plus de monde , et ils ont commencé à se gêner.
Le commerçant dépense draine le compte bancaire pour une nouvelle campagne publicitaire, il n'y a donc pas d'argent pour acheter des produits qui doivent être expédiés de toute urgence.
L'entrepôt dispose de 10 hyperdrives flambant neufs qui sont expédiés à un client une fois par mois. Un coursier est arrivé par avion et a emporté un hyper drive pour un autre client, ce qui a retardé d'un mois la commande régulière de 10 hyper drives. Le premier coursier ne savait tout simplement pas que l'autre commande était exécutée par le second coursier.
Le nouveau directeur adjoint envoie un courrier sur un vaisseau spatial pour acheter plus de marchandises. Pendant ce temps, tout le monde attend qu'un vaisseau spatial disponible apparaisse. Il y a des tonnes de livraisons urgentes, mais cette assistante ne supervise que les achats et essaie de bien faire son travail. Mieux un employé remplit ses fonctions, plus il interfère avec le travail des autres.
En analysant la situation, le patron se rend compte que des ressources importantes comme le vaisseau spatial, l'argent et les produits ne sont pas utilisés de manière optimale. Au lieu de cela, ils sont soumis à la règle "vous répétez, vous perdez". N'importe quel employé pourrait prendre une ressource dont tout le monde a besoin pour son travail, mettant ainsi en danger les autres employés et l'entreprise dans son ensemble.
Il fallait faire quelque chose, alors le patron a décidé de diviser l'entreprise monolithique en quelques départements. Il a créé un service d'expédition, un service marketing, un service d'approvisionnement, un service financier et un service d'inventaire. Personne ne pouvait plus simplement prendre le vaisseau spatial. Le chef du service d'expédition a reçu toutes les informations sur les livraisons et a remis le navire au courrier avec la commande la plus rentable. De plus, l'entrepôt ne permettait pas aux coursiers de simplement prendre les marchandises qu'ils voulaient. Au lieu de cela, la cueillette des produits de l'entrepôt est devenue un processus contrôlé. Le service financier ne débloquerait pas de fonds pour une campagne de marketing s'il savait qu'il y aurait bientôt un achat. Chaque département avait un visage public - le chef de département.La structure interne de chaque département était sa propre affaire. Si un coursier voulait obtenir des produits, il se rendait au responsable de l'entrepôt, pas à l'entrepôt. Si une nouvelle commande arrivait, elle était réceptionnée par le responsable du service expédition ( public-facing representative) et non par un coursier ( someone not authorized to interact with the other departments).
En d'autres termes, le patron a regroupé les ressources et les actions impliquant des ressources dans des groupes (départements) , et a également interdit aux autres d'interférer avec les structures internes des départements. Les interactions interministérielles devaient passer par une personne en particulier.
Du point de vue de la POO , ce n'est rien de plus que de diviser le programme en objets. Un programme monolithique de méthodes et de variables devient un programme composé d'objets. Et les objets ont des variables et des méthodes.
Le problème était que n'importe quel employé pouvait travailler avec n'importe quelle ressource et donner des ordres à n'importe quel autre employé, le tout sans surveillance ni contrôle. Nous avons imposé une petite restriction, mais avons obtenu plus d'ordre. Et nous avons également pu mieux tout contrôler.
C'est diviser pour régner dans sa forme la plus pure.
2. Comment les programmes sont créés
Je veux aborder un autre point important qui révèle un autre avantage de la POO . Voyez-vous que les programmes ressemblent plus à des animaux qu'à des bâtiments ? Ils ne sont pas construits. Ils sont cultivés. Le développement est un changement constant. En construction, on peut avoir un bon plan et le suivre avec précision. Ce n'est pas le cas avec le développement de logiciels.
Très souvent, en programmation, vous ne pouvez pas faire quelque chose comme vous l'aviez initialement prévu et devez beaucoup retravailler. Les exigences des clients changent encore plus souvent.
Mais que se passe-t-il si le client fournit un cahier des charges très précis ? Cela rend les choses encore pires. Jetez un œil à ce qui se passe avec le produit au fil du temps.
Le succès du produit amènera le client à vouloir sortir une nouvelle version, puis une autre et encore une autre. Et, bien sûr, tout ce que vous avez à faire est d'ajouter de "petites modifications" au produit existant. Vous pouvez donc voir que le développement de produits est une séquence de changements constants. Seule l'échelle de temps est différente. Une nouvelle version peut être publiée une fois par semaine, une fois par mois ou une fois tous les six mois.
Et quelle conclusion peut-on tirer de tout cela ? La structure interne du produit doit être maintenue de manière à permettre des modifications importantes (et mineures) avec un minimum de retouches.
Cohésion d'objet
Mais faire cela est plus difficile que de décider de le faire. Nous avons déjà dit qu'un programme est constitué d'objets qui interagissent les uns avec les autres. Dessinons tous les objets de notre programme sur le tableau, en les représentant par des points. Et dessinons des flèches de chaque objet (point) vers tous les autres objets (points) avec lesquels il interagit.
Nous allons maintenant combiner les objets (points) en groupes. Les points doivent être regroupés si les connexions entre eux sont beaucoup plus intenses que celles avec d'autres points. Si la plupart des flèches d'un point vont vers d'autres points de son propre groupe, alors les groupes ont été formés correctement. On dit que les points au sein d'un groupe ont une cohésion élevée tandis que les points dans différents groupes ont une cohésion plus faible.
Principe de couplage lâche
Il existe un "principe de couplage lâche". Un programme est divisé en plusieurs parties, qui sont souvent des couches. La logique de ces couches/parties est étroitement couplée à leur structure interne et très faiblement couplée aux autres couches/parties. Les interactions entre les couches sont généralement très réglementées. Une couche peut faire référence à la seconde couche et n'utiliser qu'un petit sous-ensemble de ses classes. C'est le principe du « découpage de l'entreprise en départements » que nous avons vu plus haut, mais à plus grande échelle.
Le résultat est que nous pouvons réorganiser un département au besoin pour augmenter son efficacité et nous pouvons embaucher encore plus de personnes pour le département, et tant que nous ne changeons pas le protocole d'interaction avec nos autres départements, alors tous les changements apportés seront restent locaux. Personne n'a rien à réapprendre. Vous n'avez pas à retravailler tout le système. Chaque département peut faire ce genre d'optimisation interne si les mécanismes d'interaction interdépartementale sont bien choisis.
Bien choisi. Mais que se passe-t-il s'ils ne sont pas bien choisis ? Ensuite, la capacité de changement est rapidement épuisée et vous devrez refaire tout le système. Cela doit être fait de temps en temps. Vous ne pouvez pas prédire l'avenir, mais vous pouvez réduire au minimum le nombre de redos.
Principe d'abstraction
Choisir comment les services sont structurés et comment ils interagissent est le « principe d'abstraction ». En programmation, il est utilisé pour déterminer la meilleure façon de diviser un programme en parties constituantes et comment ces parties doivent interagir. Nous pouvons réappliquer le principe, en divisant les parties résultantes en parties, jusqu'à ce que nous ayons décomposé le programme en classes individuelles.
Cacher la structure interne de ces pièces et limiter strictement les interactions avec d'autres pièces, c'est l'encapsulation . L'encapsulation et l'abstraction sont les pierres angulaires de la POO . Un bon programme doit suivre ces deux principes. À l'avenir, nous examinerons le reste des principes et explorerons les avantages qu'ils procurent.