Comment pratiquer la programmation orientée objet? [fermé]

J'ai toujours programmé dans des langages procéduraux et actuellement je m'oriente vers l'orientation objet. Le principal problème auquel j'ai été confronté est que je ne vois pas de manière efficace de pratiquer l'orientation des objets. Je vais expliquer mon point. Quand j'ai appris PHP et C, c'était assez facile à pratiquer: il suffisait de choisir quelque chose et de penser à un algorithme pour cette chose.

En PHP par exemple, c'était une question de s'asseoir et de penser: "eh bien, juste pour m'entraîner, permettez-moi de créer une application avec un espace d'administration où les gens peuvent ajouter des produits". C'était assez facile, il s'agissait de penser à un algorithme pour enregistrer un utilisateur, pour se connecter à l'utilisateur et pour ajouter les produits. En les combinant avec des fonctionnalités PHP, c'était une bonne façon de pratiquer.

Maintenant, dans l'orientation des objets, nous avons beaucoup de choses supplémentaires. Il ne s'agit pas seulement de penser à un algorithme, mais d'analyser les exigences plus en profondeur, d'écrire des cas d'utilisation, de trouver des diagrammes de classes, des propriétés et des méthodes, de configurer l'injection de dépendances et bien d'autres choses.

Le point principal est que dans la façon dont j'ai appris l'orientation des objets, il semble qu'un bon design soit crucial, alors que dans les langages procéduraux, une vague idée était suffisante. Je ne dis pas que dans les langages procéduraux, nous pouvons écrire de bons logiciels sans conception, juste que pour le pratiquer, c'est faisable, alors qu'en orientation objet, il ne semble pas possible de se passer d'une bonne conception, même pour la pratique.

Cela semble être un problème, car si chaque fois que je vais m'entraîner, j'ai besoin de trouver des tonnes d'exigences, des cas d'utilisation, etc., cela ne semble pas être un bon moyen d'améliorer l'orientation de l'objet, car cela nécessite moi d'avoir une idée entière pour une application à chaque fois que je vais pratiquer.

Pour cette raison, quelle est une bonne façon de pratiquer l'orientation des objets?

Maintenant, dans l'orientation des objets, nous avons beaucoup de choses supplémentaires.

Non tu ne sais pas ...

Il ne s'agit pas seulement de penser à un algorithme, mais d'analyser les exigences plus en profondeur, d'écrire des cas d'utilisation, de trouver des diagrammes de classes, des propriétés et des méthodes, de configurer l'injection de dépendances et bien d'autres choses.

Aucune de ces choses n'est nécessaire pour pratiquer la programmation orientée objet.

C'était assez facile, il s'agissait de penser à un algorithme pour enregistrer un utilisateur, pour se connecter à l'utilisateur et pour ajouter les produits.

Toute la programmation orientée objet est au lieu de penser aux algorithmes pour effectuer ces étapes, vous pensez aux objets nécessaires pour effectuer ces étapes - quelle fonctionnalité vous voulez, quel état est nécessaire pour le faire, et quel type d'interface vous souhaitez exposer à l'utilisateur. Tout comme vous devez le faire dans la programmation procédurale.

La seule différence est qu'au lieu de se concentrer sur les fonctions dont vous avez besoin et comment elles fonctionnent, vous vous concentrez sur la façon dont la fonctionnalité et l'état sont regroupés en responsabilités, et comment ces responsabilités interagissent.

Comment pratiquer? De la même manière que vous pratiquez la programmation procédurale: choisissez un problème et résolvez le problème en utilisant des ensembles de classes. Découvrez comment cela a été nul, répétez avec les leçons apprises.

Bonne question. Bien sûr, ce que vous dites, c'est que pratiquer la POO signifie en fait pratiquer toutes ces choses (analyse des exigences, cas d'utilisation, modèles de conception, etc.), ce qui est vrai et peut sembler intimidant au premier abord.

Mon conseil serait de commencer vos séances d'entraînement en gardant deux choses à l'esprit: le développement piloté par les tests et le principe de responsabilité unique .

Ensuite, commencez comme vous l'avez fait avec PHP / C: trouvez une idée, réfléchissez à ce dont vous avez besoin et implémentez ces choses l'une après l'autre. Cependant, gardez à l'esprit que vous devez commencer par les tests (ce qui vous oblige à définir les interfaces appropriées, car sinon la testabilité en souffre immédiatement) et que TDD implique un cycle rouge-vert-refactor. En d'autres termes, vous avez un tout petit peu de fonctionnalités, et une fois que cela fonctionne, vous refactorisez pour obtenir une conception OO appropriée si vous ne l'avez pas faite dès le départ (ce que vous ne ferez pas).

Lorsque vous effectuez cette étape de refactoring, rappelez-vous toujours le SRP. Si vous avez ajouté une deuxième responsabilité à votre objet, il est temps de créer quelque chose de nouveau.

Lorsque vous développez comme ça, vous devez être conscient que votre solution finale sera très différente de ce que vous avez commencé. Votre courbe d'apprentissage sera également assez abrupte. Par exemple, vous n'apprendrez pas ce qu'est un modèle Factory, mais vous reconnaîtrez plutôt le besoin de quelque chose qui crée des instances de votre classe de différentes manières. Donc, si vous n'avez pas du tout entendu parler de modèles de conception orientés objet, il est bon de les lire en parallèle.

Si vous débutez dans la POO, vous pouvez vous amuser et vous "entraîner" hors ligne en examinant à peu près n'importe quel système du monde réel et en considérant quels sont les objets et quelle est la relation entre eux et quelles méthodes / interfaces ils pourraient prendre en charge et comment vous les représenteriez dans une hiérarchie de classes et comme une collection d'objets instanciés et quelles seraient les relations de propriété des objets, etc. (note: je ne mentionne pas du tout le mot "algorithmes" ci-dessus). Dessiner beaucoup de diagrammes (apprenez un peu d'UML ou similaire) avant de penser à coder quoi que ce soit.

Cela vous aidera à développer un bien meilleur sens des relations IS-A et HAS-A , qui est probablement la classification la plus importante de toute conception de POO (et malgré cela, il semble toujours être quelque chose avec lequel de nombreux programmeurs de langage POO chevronnés ont du mal à ). Si vous maîtrisez IS-A / HAS-A, il y a aussi IS-IMPLEMENTED-IN-TERM-OF (que j'ai également vu décrit comme IS-KIND-OF-A: ^)

Sérieusement, lors de votre prochain voyage au supermarché, imaginez que quelqu'un vous a confié la tâche de rédiger une simulation OOP du lieu ...

Ce dont je me souviens de mon temps C (très loin dans le passé), nous avions l'habitude de séparer les fonctions et les procédures dans différents fichiers en fonction de leur responsabilité. Je ne prétends pas que ce soit parfait ou quoi que ce soit, mais c'était un bon point de départ pour quand j'ai commencé à programmer dans des langages orientés objet. Alors peut-être que vous pourriez commencer par convertir des fichiers en objets.

En ce qui concerne la POO, il s'agit vraiment de pratiquer et de rechercher l'amélioration. Rarement personne ne l'obtient dès le départ. Ainsi, les itérations se produisent tout au long du cycle de vie du projet.

Ajoutons un peu de terminologie, d' analyse orientée objet et de conception orientée objet , comme l'a fait Peter Coad dans les années 1990.

Ensemble, ils forment une discipline de génie logiciel OOAD qui peut (bien fait) soutenir le programmeur au moment de l'écriture et du test du code. La programmation orientée objet peut alors avoir son niveau de granularité approprié, une utilisation habile des fonctionnalités du langage de programmation pour répondre aux objectifs fonctionnels et aux exigences de conception spécifiés au niveau du projet.

Parfois, c'est un projet pour une seule personne, et puis vous devez porter tous les chapeaux (mais pas nécessairement tous en même temps). Je suis un grand fan du développement piloté par les tests pour mes propres projets personnels (voir la recommandation de Frank), mais cela ne concerne pas uniquement le développement logiciel orienté objet.

Dans un projet d'équipe, une bonne répartition des responsabilités est la clé d'une mise en œuvre réussie. L'utilisation habile des modèles de conception orientés objet aide les équipes à comprendre en limitant les interfaces visibles nécessaires à l'analyse, aux flux de données et à la logique métier pour partager un cadre utilisable.

"eh bien, juste pour m'entraîner, permettez-moi de créer une application avec un espace d'administration où les gens peuvent ajouter des produits". C'était assez facile, il s'agissait de penser à un algorithme pour enregistrer un utilisateur, pour se connecter à l'utilisateur et pour ajouter les produits.

Pourquoi ne pas faire la même chose cette fois-ci avec les objets utilisateurs et les objets produits? De plus, si vous utilisez un langage qui prend en charge à la fois les procédures et l'OO, vous pouvez essayer d'implémenter des objets basés sur la bibliothèque standard de procédures, comme un objet fichier.