Qu'est-ce que le processus de pensée orienté objet? [fermé]

J'ai étudié la POO en conjonction avec l'implémentation MVC de Zend au cours des derniers mois. Je suis assez nouveau dans la programmation, en général, mais je suis convaincu que je dois apprendre les choses de la bonne manière, ce qui signifie pour moi de m'assurer que je comprends pourquoi les choses se font comme elles le sont. C'est-à-dire que j'ai découvert qu'en apprenant à faire quelque chose (n'importe quoi, par exemple de la musique), la meilleure façon d'apprendre à faire quelque chose est de savoir pourquoi cela a été fait de cette façon en premier lieu.

Quoi qu'il en soit, j'ai eu beaucoup de mal à comprendre comment développer mes propres modèles commerciaux (c'est-à-dire le M de MVC), et j'ai décidé que ce n'était pas parce que je ne comprenais pas la POO en général, parce que je l'avais étudié pendant plusieurs mois et je ne pense pas que les concepts soient très difficiles à saisir. En fait, je trouve les exemples que j'ai étudiés très intuitifs. Le problème pour moi, je pense, réside dans le processus de traduction de mes propres problèmes en solutions orientées objet. Les exemples dans les livres (que j'ai lus jusqu'à présent) sont trop évidents, donc le processus de traduction du problème en objets n'est pas très difficile. Je pense que je pourrais manquer un processus abstrait de haut niveau. Une sorte de liste d'étapes ou de questions auxquelles chaque solution orientée objet doit répondre au plus haut niveau.

Si vous deviez décrire un tel processus en cinq étapes au maximum, quels seraient-ils et pourquoi? Quel est le processus le plus efficace pour traduire un problème en une solution orientée objet?

Trouver un modèle adapté n'est pas toujours simple. C'est une de ces choses qui nécessite plus d'expérience que de simples connaissances. Cependant, la recette simple suivante pourrait vous aider à surmonter un blocage mental initial.

Il a été initialement décrit dans ce document par Abbott et est souvent appelé "l'analyse textuelle d'Abbott".

1. Écrivez une spécification de texte brut.
2. Identifier les classes: les noms sont de bons candidats.
3. Trouvez les attributs: les adjectifs / adverbes sont de bons candidats.
4. Trouvez les opérations: les verbes sont de bons candidats.
5. Trouvez les associations entre les classes.
6. Affiner.

Exemple:

Les noms , les verbes et adjectivessont marqués.

La bibliothèque contient des livres et des revues . Il peut contenir plusieurs exemplaires d'un livre donné . Certains livres sont short-term réservés aux prêts . Tous les autres livres peuvent être empruntés par n'importe quel membre de la bibliothèque pendant trois semaines. Les membres de la bibliothèque peuvent normalement emprunter jusqu'à six articles à la fois, mais les membres du personnel peuvent emprunter jusqu'à 12 articles à la fois. Seuls les membres du personnel peuvent emprunter des revues .

Une première itération d'analyse donnerait:

Des classes:

• Bibliothèque
• Livre, Journal
• Copie
• Prêt
• Membre de la bibliothèque
• Article
• Membre du staff

À partir de là, vous pouvez penser à quelle classe a besoin de quels attributs et méthodes pour implémenter le comportement, puis affiner ce modèle de plus en plus.

À mon avis, adopter l'approche TDD est naturel et efficace:

1. Notez les exigences spécifiques (données, quand, alors)
2. Traduisez chaque exigence (la plus importante en premier) en un test unitaire.
3. Écrivez le moins de code pour réussir le test écrit en # 2.
4. Après avoir réussi le test, refactorisez votre code selon les principes de conception SOLIDD.
5. Après # 4, assurez-vous que votre code passe toujours tous les tests écrits.
6. Répétez 2-5.

Avec ce processus, vous pouvez progressivement produire du code testable avec une conception sonore. Vous pourriez penser au début que le test d'écriture n'est pas nécessaire, mais cette activité vous aide à construire une architecture sonore.

Voici les étapes que j'utilise dans le code c ++:

1. décider du nom de la classe
2. décider des paramètres du constructeur et des membres de données.
3. décider des noms de fonction des membres et des prototypes
4. le rendre indépendant des autres classes
5. La conception est terminée et tout le reste n'est que la mise en œuvre.

La raison de (1) est qu'elle définit la portée de quelle fonctionnalité appartient à la classe. La raison de (2) est qu'elle définit la façon dont la classe communique avec le monde extérieur. La raison de (3) est qu'elle définit comment choisir la fonctionnalité de la classe qui est nécessaire dans chaque situation. La raison de (4) est qu'elle permet d'utiliser la classe dans de nombreuses situations différentes. La raison de (5) est qu'elle définit la frontière entre la conception et la mise en œuvre.