Je pense que cela convient mieux lorsque vous modélisez quelque chose de cohérent avec l'état et les actions associées sur ces états. Je suppose que c'est un peu vague, mais je ne suis pas sûr qu'il y ait une réponse parfaite ici.

La particularité de la POO est qu'elle vous permet d'encapsuler et d'abstraire des données et des informations, ce qui est une véritable aubaine pour la construction d'un grand système. Vous pouvez faire la même chose avec d'autres paradigmes, mais il semble que la POO soit particulièrement utile dans cette catégorie.

Cela dépend aussi de la langue que vous utilisez. S'il s'agit d'un langage avec un support OOP riche, vous devriez probablement l'utiliser à votre avantage. Si ce n'est pas le cas, vous devrez peut-être trouver d'autres mécanismes pour diviser le problème en éléments plus petits et facilement testables.

Je suis vendu à OOP.

Chaque fois que vous pouvez définir un concept pour un problème, il peut probablement être enveloppé dans un objet.

Le problème avec la POO est que certaines personnes en ont trop utilisé et ont rendu leur code encore plus difficile à comprendre. Si vous faites attention à ce que vous mettez dans les objets et à ce que vous mettez dans les services (classes statiques), vous bénéficierez de l'utilisation des objets.

Ne mettez simplement pas quelque chose qui n'appartient pas à un objet dans l'objet parce que vous avez besoin que votre objet fasse quelque chose de nouveau auquel vous n'aviez pas pensé au départ, refactorisez et trouvez le meilleur moyen d'ajouter cette fonctionnalité.< /p>

Il n'y a pas de règle absolue. Un problème est mieux résolu avec la POO lorsque vous êtes meilleur pour résoudre les problèmes et penser dans une mentalité OO. L'orientation objet n'est qu'un outil parmi d'autres qui est apparu en essayant de faire de l'informatique un meilleur outil pour résoudre des problèmes.

Cependant, cela peut permettre une meilleure réutilisation du code et peut également conduire à un code plus clair. Mais bien souvent ces qualités hautement louées sont, en réalité, de peu de valeur réelle. L'application de techniques OO à une application fonctionnelle existante peut vraiment causer beaucoup de problèmes. La compétence réside dans l'apprentissage de nombreuses techniques différentes et dans l'application de la plus appropriée au problème à résoudre.

OO est souvent cité comme une solution de type Nirvana pour le développement de logiciels, mais il arrive souvent qu'il ne soit pas approprié de l'appliquer au problème en question. Cela peut, assez souvent, conduire à une ingénierie excessive d'un problème pour atteindre la solution parfaite, alors que souvent ce n'est vraiment pas nécessaire.

Essentiellement, la POO n'est pas vraiment de la programmation orientée objet, mais mappe la pensée orientée objet vers un langage de programmation capable de prendre en charge les techniques OO. Les techniques OO peuvent être prises en charge par des langages qui ne sont pas intrinsèquement OO, et il existe des techniques que vous pouvez utiliser dans les langages fonctionnels pour tirer parti des avantages.

A titre d'exemple, je développe des logiciels OO depuis environ 20 ans maintenant, donc j'ai tendance à penser en termes OO lors de la résolution de problèmes, quel que soit le langage dans lequel j'écris. Actuellement, j'implémente le polymorphisme en utilisant Perl 5.6, qui ne le supporte pas nativement. J'ai choisi de le faire car cela fera de la maintenance et de l'extension du code une simple tâche de configuration, plutôt qu'un problème de développement.

Je ne sais pas si c'est clair. Il y a des gens qui sont durs au tribunal OO et il y a des gens qui sont durs au tribunal fonctionnel. Et puis il y a des gens qui ont essayé les deux et essaient de tirer le meilleur de chacun. Ni l'un ni l'autre n'est parfait, mais les deux ont de très bons traits que vous pouvez utiliser quelle que soit la langue.

Si vous essayez d'apprendre la POO, ne vous concentrez pas uniquement sur la POO, mais essayez d'utiliser l'analyse orientée objet et les principes généraux de l'OO pour tout le spectre de la solution au problème.

La clé de l'apprentissage de la programmation orientée objet est l'apprentissage du modèle de conception. En vous familiarisant avec les modèles de conception, vous pouvez mieux voir quand les cours sont nécessaires et quand ils ne le sont pas. Comme tout ce qui est utilisé dans la programmation, l'utilisation de classes et d'autres fonctionnalités des langages POO dépend de votre conception et de vos besoins. Comme les algorithmes, les modèles de conception sont un concept de niveau supérieur.

Un modèle de conception joue un rôle similaire à celui des algorithmes pour les langages de programmation traditionnels. Un modèle de conception vous indique comment créer et combiner un objet pour effectuer une tâche utile. Comme les meilleurs algorithmes, les meilleurs modèles de conception sont suffisamment généraux pour être appliqués à une variété de problèmes courants.

À mon avis, c'est plus une question sur vous en tant que personne. Certaines personnes pensent mieux en termes fonctionnels et d'autres préfèrent les classes et les objets. Je dirais que la POO est mieux adaptée lorsqu'elle correspond à votre modèle mental interne (subjectif) du monde.

Cela dépend du problème : le paradigme OOP est utile pour concevoir des systèmes distribués ou un framework avec beaucoup d'entités vivant pendant les actions de l'utilisateur (exemple : application Web).

Mais si vous avez un problème de mathématiques, vous préférerez un langage fonctionnel (LISP) ; pour un système à performance critique, vous utiliserez ADA ou C, etc etc.

Le langage POO est utile car lui aussi utilise probablement le ramasse-miettes (utilisation automatique de la mémoire) dans le déroulement du programme : vous programmez en C beaucoup de temps vous devez déboguer et corriger manuellement un problème de mémoire.

Le code orienté objet et le code procédural ont des points d'extensibilité différents. Les solutions orientées objet facilitent l'ajout de nouvelles classes sans modifier les fonctions existantes (voir le principe ouvert-fermé), tandis que le code procédural vous permet d'ajouter des fonctions sans modifier les structures de données existantes. Très souvent, différentes parties d'un système nécessitent des approches différentes selon le type de changement anticipé.