Jusqu'à présent dans cette série, nous avons discuté de la programmation orientée objet en général et du principe de cohésion du POO. Dans cet article, nous allons examiner le principe de couplage et comment cela aide au développement de jeux.
Remarque: Bien que ce tutoriel ait été écrit en Java, vous devriez pouvoir utiliser les mêmes techniques et concepts dans presque tous les environnements de développement de jeux..
Le couplage est le principe de "séparation des préoccupations". Cela signifie qu'un objet ne change ni ne modifie directement l'état ou le comportement d'un autre objet.
Le couplage examine les relations entre les objets et leur lien étroit. Un diagramme de relations est un excellent moyen de visualiser les connexions entre les objets. Dans un tel diagramme, les boîtes représentent les objets et les flèches représentent une connexion entre deux objets, un objet pouvant affecter directement un autre objet..
HTML et CSS sont un bon exemple de couplage. Avant CSS, HTML était utilisé à la fois pour le balisage et la présentation. Cela a créé un code saturé qu'il était difficile de modifier et de maintenir. Avec l'avènement de CSS, HTML a été utilisé uniquement pour le balisage, et CSS a pris le relais pour la présentation. Cela a rendu le code assez propre et facilement modifiable. Les préoccupations de présentation et de balisage ont été séparées.
Les objets indépendants les uns des autres et qui ne modifient pas directement l'état des autres objets sont dits couplage lâche. Le couplage lâche rend le code plus flexible, plus modifiable et plus facile à utiliser.
Les objets qui reposent sur d’autres objets et peuvent modifier les états d’autres objets sont dits couplage étroit. Le couplage étroit crée des situations dans lesquelles la modification du code d'un objet nécessite également de modifier le code des autres objets (également appelé effet d'entraînement). Le code étroitement couplé est également plus difficile à réutiliser car il ne peut pas être séparé.
Une expression courante que vous entendrez est "s'efforcer d'obtenir un faible couplage et une cohésion élevée". Cette phrase est un rappel utile que nous devrions rechercher un code qui sépare les tâches et ne repose pas beaucoup sur les autres. Ainsi, un couplage faible (ou lâche) est généralement bon, alors qu'un couplage élevé (ou serré) est généralement mauvais.
Tout d'abord, regardons les objets des astéroïdes et comment ils sont connectés. Rappelez-vous que les objets sont un navire, un astéroïde, une soucoupe volante et une balle. Comment ces objets sont-ils liés ou connectés les uns aux autres??
Dans les astéroïdes, un navire peut tirer une balle, une balle peut toucher un astéroïde et une soucoupe volante, et un astéroïde et une soucoupe volante peuvent frapper le navire. Notre diagramme de relations se présente alors comme suit:
Comme vous pouvez le constater, les objets sont tous très bien liés. Pour cette raison, nous devons faire attention à la façon dont nous écrivons le code, sinon nous nous retrouverons avec un système étroitement couplé. Prenons par exemple le navire qui tire une balle. Si le navire créait un objet de balle, gardait une trace de sa position, puis modifiait l'astéroïde lorsque la balle frappait, notre système serait très étroitement couplé..
Au lieu de cela, le navire devrait créer un objet balle, mais ne vous inquiétez pas après cela. Une autre classe serait chargée de garder une trace de la position de la balle ainsi que de ce qui se passe quand une balle frappe un astéroïde. Avec une classe intermédiaire entre nos relations, le diagramme ressemblerait à ceci:
Ce diagramme de relations est beaucoup plus esthétique et crée un système très faiblement couplé. Dans ce système, si nous ajoutions un objet, tel qu'un météore, nous pourrions facilement le faire sans devoir modifier le fonctionnement du vaisseau ou des objets-balles - nous laisserions simplement notre classe intermédiaire s'occuper de tout..
Comme il n'y a qu'un seul objet dans Tetris, le Tetrimino, le couplage ne pose pas vraiment de problème car il ne peut y avoir de relation avec d'autres objets..
Pour Pac-Man, un couplage étroit pourrait se produire lorsque Pac-Man mange une pastille électrique. Quand un aliment est mangé, Pac-Man peut alors manger des fantômes et son état devient mangeable
. Si l'objet Pac-Man devait suivre le moment où il a mangé une pastille d'énergie, puis initier le changement d'état de chaque fantôme, le système serait étroitement couplé.
Encore une fois, une autre classe est nécessaire pour garder une trace de cette information et la traiter afin que nos objets puissent être couplés de manière lâche. Vous trouverez ci-dessous un exemple de la façon dont une classe intermédiaire pourrait suivre Pac-Man mangeant une pastille énergétique.
/ ** * Classe intermédiaire qui garde la trace des événements du jeu * / public class Game … if (Pac-Man.eats (Power_Pellet)) Ghosts.changeState (); …
Le couplage est le principe de réduction de la manière dont les objets affectent directement les états et les comportements des autres objets. Le couplage permet de créer un code plus facile à lire et à modifier..
Dans le prochain conseil, nous discuterons du principe de encapsulation et pourquoi cela aide à créer du code maintenable. Suivez-nous sur Twitter, Facebook ou Google+ pour vous tenir au courant des derniers messages..