utilisations pratiques de la POO

https://stackoverflow.com/questions/1761109

21-09-2019
|

Question

J'ai eu récemment un débat avec un collègue qui n'est pas fan de POO . Ce qui a pris mon attention était ce qu'il a dit:

"Quel est le point de faire mon codage dans les objets? Si elle est réutilisation alors je peux créer une bibliothèque et appeler les fonctions dont j'ai besoin pour toute tâche est à portée de main. Ai-je besoin de ces concepts de polymorphisme, héritage, interfaces, modèles ou quoi? "

Nous sommes dans une petite entreprise de développement de petits projets pour les sites de commerce électronique et les biens immobiliers.

Comment puis-je tirer parti de la POO dans une configuration « tous les jours, dans le monde réel »? Ou était-POO vraiment destiné à résoudre des problèmes complexes et non destinés au développement « de tous les jours »?

La solution

Les bonnes choses au sujet de la POO viennent de lier un ensemble de données à un ensemble de comportements.

Donc, si vous devez faire de nombreuses opérations connexes sur un ensemble connexe de données, vous pouvez écrire de nombreuses fonctions qui fonctionnent sur une struct, ou vous pouvez utiliser un objet.

Objets vous donner un peu d'aide de la réutilisation du code sous la forme d'héritage.

IME, il est plus facile de travailler avec un objet avec un ensemble connu d'attributs et les méthodes qu'il est de garder un ensemble de struct complexes et les fonctions qui opèrent sur eux.

Certaines personnes vont aller sur le sujet héritage et le polymorphisme. Ces données sont utiles, mais la valeur réelle en POO (à mon avis) vient de la bonne façon, il encapsule et données associés à des comportements.

Si vous utilisez POO sur vos projets? Cela dépend de la façon dont votre langue prend en charge la POO. Cela dépend des types de problèmes que vous devez résoudre.

Mais, si vous faites de petits sites Web, vous parlez encore de suffisamment la complexité que j'utiliser la conception de POO donné un soutien adéquat dans la langue de développement.

Autres conseils

Mon point de vue personnel: contexte

Lorsque vous programmez en POO, vous avez une plus grande prise de conscience du contexte. Il vous aide à organiser le code de telle sorte qu'il est plus facile à comprendre parce que le monde réel est également orienté objet.

Plus que de faire quelque chose à travailler juste - point de votre ami, une conception orientée objet bien conçu est plus facile à comprendre, de suivre, de se développer, d'étendre et à mettre en œuvre. Il est tellement plus facile par exemple de déléguer le travail qui sont catégoriquement similaires ou pour conserver des données qui doivent rester ensemble (oui, même une struct C est un objet).

Eh bien, je suis sûr que beaucoup de gens vont donner beaucoup plus académique répond correctement, mais voici mon avis sur quelques-unes des avantages les plus précieux:

POO permet une meilleure encapsulation
POO permet au programmeur de penser en termes logiques, ce qui rend les projets logiciels plus faciles à concevoir et à comprendre (si bien conçu)
POO est un gain de temps. Par exemple, regardez les choses que vous pouvez faire avec un C ++ objet chaîne, vecteurs, etc. Toutes ces fonctionnalités (et beaucoup plus) vient pour « libre ». Maintenant, ce sont vraiment des caractéristiques les bibliothèques de classes et ne pas s'oop, mais presque toutes les implémentations POO viennent avec les bibliothèques de classes agréables. Pouvez-vous mettre en œuvre tout ce genre de choses en C (ou la plus grande partie)? Sûr. Mais pourquoi écrire vous-même?

Regardez l'utilisation des modèles de conception et vous verrez l'utilité de la POO. Il n'y a pas que l'encapsulation et la réutilisation, mais l'extensibilité et la maintenabilité. Ce sont les interfaces qui font des choses puissantes.

Quelques exemples:

La mise en œuvre d'un courant (motif de décorateur) sans objets est difficile
Ajout d'une nouvelle opération à un système existant, comme un nouveau type de cryptage (modèle de stratégie) peut être difficile sans objets.
Regardez la façon dont est PostgresQL mis en œuvre par rapport à la façon dont votre base de données livre dit une base de données devrait être mis en œuvre et vous verrez un grand différence. Le livre suggère noeud objets pour chaque opérateur. Postgres utilise des tables et une myriade macros pour tenter d'imiter ces nœuds. Il est beaucoup moins jolie et bien plus difficile à étendre à cause de cela.

La liste est longue.

La puissance de la plupart des langages de programmation est dans les abstractions qu'ils mettent à la disposition. La programmation orientée objet fournit un système très puissant d'abstractions de la façon dont il vous permet de gérer les relations entre les idées liées ou actions.

Considérons la tâche de calcul des zones pour un arbitraire et l'expansion collection de formes. Tout programmeur peut rapidement écrire des fonctions pour la zone d'un cercle, carré, triangle, ect. et de les stocker dans une bibliothèque. La difficulté vient lorsque vous essayez d'écrire un programme qui identifie et calcule la surface d'une forme arbitraire. Chaque fois que vous ajoutez un nouveau type de forme, par exemple un pentagone, vous devez mettre à jour et d'étendre quelque chose comme une IF ou une structure CASE pour permettre à votre programme pour identifier la nouvelle forme et appeler la routine de la zone correcte de votre « bibliothèque de fonctions » . Après un certain temps, les coûts d'entretien associés à cette approche commencent à empiler.

Avec la programmation orientée objet, beaucoup de cela vient free-- définir juste une classe de forme qui contient une méthode de zone. Ensuite, il n'a pas vraiment d'importance quelle forme spécifique que vous avez affaire à au moment de l'exécution, il suffit de faire chaque figure géométrique d'un objet qui hérite de forme et appeler la méthode de la zone. Le paradigme orienté objet traite les détails de que ce soit à ce moment dans le temps, avec cette entrée utilisateur, avons-nous besoin de calculer l'aire d'un cercle, triangle, carré, pentagone ou l'option d'ellipse qui vient d'être ajouté il y a une demi-minute.

Que faire si vous avez décidé de changer l'interface derrière la façon dont la fonction de zone a été appelée? Avec la programmation orientée objet vous simplement mettre à jour la classe de forme et les modifications se propagent automagiquement à toutes les entités qui héritent de cette classe. Avec un système orienté non objet que vous serez face à la tâche de piocher dans votre « bibliothèque de fonctions » et la mise à jour chaque interface individuelle.

En résumé, la programmation orientée objet fournit une puissante forme d'abstraction qui peut vous faire gagner du temps et de l'effort en éliminant la répétition dans votre code et la rationalisation des extensions et la maintenance.

Tous les paradigmes de programmation ont le même objectif: masquer la complexité inutile.

Certains problèmes sont facilement résolus avec un paradigme impératif, comme votre ami utilise. D'autres problèmes sont facilement résolus par un paradigme orienté objet. Il y a beaucoup d'autres . Les principales (programmation logique, programmation fonctionnelle, et de programmation impératif) sont tous équivalents les uns aux autres; est généralement pensé programmation orientée objet comme une extension de la programmation impérative.

La programmation orientée objet est mieux utilisé lorsque le programmeur est la modélisation des éléments qui sont similaires, mais pas le même. Un paradigme impératif placerait les différents types de modèles en une seule fonction. Un paradigme orienté objet sépare les différents types de modèles dans différentes méthodes sur des objets connexes.

Votre collègue semble être coincé dans un paradigme. Bonne chance.

Autour de 1994, je tentais de comprendre POO et C ++ en même temps, et me suis retrouvé frustré, même si je pouvais comprendre, en principe, quelle était la valeur de la POO. Je suis tellement habitué à être en mesure de jouer avec l'état d'une partie de l'application d'autres langues (la plupart du temps de base, l'Assemblée, et les langues Pascal-famille) qu'il semblait que je renonçais la productivité en faveur d'une abstraction académique. Malheureusement, mes premières rencontres avec les cadres OO comme MFC il est plus facile de pirater, mais ne fournissent pas nécessairement beaucoup de la manière de l'illumination.

Ce ne fut que grâce à une combinaison de la persistance, l'exposition à alterner (non C ++) façons de traiter les objets, et une analyse minutieuse du code OO que les deux 1) ouvragé et 2) lire de façon plus cohérente et intuitive que le code de procédure équivalent que j'ai commencé à vraiment. Et 15 ans plus tard, je suis régulièrement surpris de nouveau (pour moi) de découvertes ingénieuses, mais impressionnante des solutions simples OO que je ne peux pas imaginer faire comme parfaitement dans une approche procédurale.

J'ai traversais la même série de luttes qui tentent de donner un sens du paradigme de programmation fonctionnelle au cours des deux dernières années. Pour paraphraser Paul Graham, lorsque vous êtes à la recherche sur le continuum de puissance, vous voyez tout ce qui manque. Lorsque vous êtes à la recherche le continuum de puissance, vous ne voyez pas le pouvoir, vous voyez juste bizarreries.

Je pense que, pour engager à faire quelque chose d'une manière différente, vous devez 1) voir quelqu'un évidemment être plus productif avec des constructions plus puissantes et 2) suspendre l'incrédulité lorsque vous vous trouvez frapper un mur. Il aide probablement d'avoir un mentor qui est au moins un tout petit peu plus loin dans leur compréhension du nouveau paradigme, aussi.

Sauf la jugeote nécessaire de suspendre l'incrédulité, si vous voulez que quelqu'un Grok rapidement la valeur d'un modèle OO, je pense que vous pourriez faire bien pire que de demander à quelqu'un de passer une semaine avec le livre de programmation Pragmatique on Rails. Il ne dispose malheureusement laisser un grand nombre de détails de la façon dont la magie fonctionne, mais il est une très bonne introduction à la puissance d'un système d'abstractions OO. Si, après avoir travaillé dans ce livre, votre collègue ne voit toujours pas la valeur de OO pour une raison quelconque, il / elle peut être un cas désespéré. Mais s'ils sont prêts à dépenser un peu de temps de travail avec une approche qui a une conception orientée objet fortement opiniâtres qui fonctionne, et les obtient de 0-60 beaucoup plus rapide que de faire la même chose dans un langage procédural, il peut être juste espoir. Je pense que c'est vrai même si votre travail ne comporte pas le développement web.

Je ne suis pas sûr que la mise en place du « monde réel » serait autant un point de vente en tant que cadre de travail pour la rédaction de bonnes applications, car il se trouve que, en particulier dans les langues statiquement typé comme C # et Java, la modélisation le monde réel nécessite souvent des abstractions tortueuses. Vous pouvez voir un exemple concret de la difficulté de modéliser le monde réel en regardant des milliers de personnes qui luttent pour modéliser quelque chose d'aussi simple que ostensiblement l'abstraction géométrique de « forme » (forme, ellipse, cercle).

Pour moi, la puissance de la POO ne se montre pas jusqu'à ce que vous commencez à parler de l'héritage et le polymorphisme.

Si un argument est pour POO repose le concept d'encapsulation et de l'abstraction, bien ce n'est pas un argument très convaincant pour moi. Je peux écrire une immense bibliothèque et documenter que les interfaces à ce que je veux que l'utilisateur soit au courant, ou je peux compter sur des constructions au niveau des langues comme des paquets en Ada pour faire des champs privés et seulement exposer ce qu'il est que je veux exposer.

Cependant, l'avantage réel vient quand j'ai un code écrit dans une hiérarchie générique afin qu'il puisse être réutilisé plus tard de telle sorte que les mêmes interfaces de code exactes sont utilisées pour des fonctionnalités différentes pour obtenir le même résultat.

Pourquoi est-ce à portée de main? Parce que je peux tenir debout sur les épaules de géants pour accomplir ma tâche en cours. L'idée est que je peux faire bouillir les parties d'un problème à les parties les plus élémentaires, les objets qui composent les objets qui la composent ... les objets qui composent le projet. En utilisant une classe qui définit le comportement très bien dans le cas général, je peux utiliser ce même code éprouvée pour construire une version plus spécifique de la même chose, puis une version plus spécifique de la même chose, puis encore un encore plus précis version de la même chose. La clé est que chacune de ces entités a communité qui a déjà été codé et testé, et il n'y a pas besoin de reimpliment encore plus tard. Si je ne me héritage pour cela, je finis par réimplémentant les fonctionnalités communes ou lier explicitement mon nouveau code contre l'ancien code, qui fournit un scénario pour moi de présenter des bugs de contrôle de flux.

Polymorphisme est très pratique dans les cas où je dois obtenir une certaine fonctionnalité d'un objet, mais la même fonctionnalité est également nécessaire de similaire, mais les types uniques. Par exemple, dans Qt, il y a l'idée d'insérer des éléments sur un modèle afin que les données peuvent être affichées et vous pouvez facilement maintenir les métadonnées pour cet objet. Sans polymorphisme, je dois me embêter avec beaucoup plus de détails que moi actuellement (par exemple je aurais besoin de mettre en œuvre les mêmes interfaces de code qui mènent la même logique métier que l'élément qui était initialement prévu pour aller sur le modèle). Parce que la classe de base de mon objet lié aux données interagit nativement avec le modèle, je peux insérer des métadonnées à la place sur ce modèle sans problème. Je reçois ce que je dois sortir de l'objet sans souci sur ce qui a besoin du modèle, et le modèle obtient ce qu'il a besoin sans se soucier de ce que j'ai ajouté à la classe.

Demandez à votre ami de visualiser tout objet dans sa salle, Maison ou ville ... et s'il peut dire un seul tel objet un système en lui-même et est capable de faire un travail significatif .
de Things comme un bouton isnt faire quelque chose seul - il faut beaucoup d'objets pour faire un appel téléphonique.
De même un moteur de voiture est fait de l'arbre de manivelle, pistons, bougies d'allumage. OOPS concepts ont évolué à partir de notre perception dans les processus naturels ou des choses dans nos vies.
Le livre « Inside COM » indique le but de COM en prenant l'analogie d'un jeu d'enfant d'identifier les animaux en posant des questions.

Conception technologie et la méthodologie l'emporte. Les bons modèles ont tendance à incorporer principes universels de la gestion de la complexité, comme la loi de Déméter qui est au cœur de ce que les fonctionnalités du langage OO visent à codifier.

Une bonne conception ne dépend pas de l'utilisation des fonctionnalités du langage spécifique OO bien qu'il soit généralement dans ceux intérêt à les utiliser.

Non seulement est-il

programmation plus facile / plus maintenable dans la situation actuelle pour les autres (et vous)
Il est déjà plus facile permettant des opérations CRUD base de données (création, mise à jour, Supprimer).

Vous trouverez de plus amples informations à ce sujet regardant: - Java: Mise en veille prolongée - Dot Net: Entity Framework

Voir même comment LINQ (Visual Studio) peut rendre votre vie de programmation beaucoup plus facile.

En outre, vous pouvez commencer à utiliser des modèles de conception pour résoudre les problèmes de la vie réelle (modèles de conception sont tout OO)

Peut-être il est même amusant de démontrer avec une petite démo:

Disons que vous devez stocker les employés, les comptes, les membres, les livres dans un fichier texte d'une manière similaire.

.PS. Je l'ai essayé d'écrire d'une manière PSEUDO:)

la voie OO

Code de vous appelez: io.file.save (objectsCollection.ourFunctionForSaving ())

objectsCollection de classe

ourFunctionForSaving fonction ()

As String

Chaîne _Objects

   for each _Object in objectsCollection
         Objects &= _Object & "-"
   end for

_Objects de retour Procédé de fin

Way NON OO

Je ne pense pas que je vais écrire en bas du code non-oo. Mais penser:)

Vivons ce Say

Dans la voie OO. La classe ci-dessus est la classe mère de toutes les méthodes pour sauver les livres, les employés, les membres, les comptes, ... Que faire si nous voulons changer la façon de sauver dans un fichier texte? Par exemple, pour le rendre compactible avec une norme actuelle (.csv).

Et disons que nous aimerions ajouter une fonction de charge, ainsi que le code avez-vous besoin d'écrire? La manière OO- vous avez seulement besoin ajouter une nouvelle méthode Sub qui peut diviser toutes les données en paramètres (Cela se produit une fois).

Laissez votre collegue penser que:)

Dans les domaines où l'état et le comportement sont mal alignés, orienté objet permet de réduire la densité globale de la dépendance (à savoir la complexité) au sein de ces domaines, ce qui rend les systèmes résultant moins fragile.

En effet, le essence de l'objet-orientation est basée sur le fait que, organisationnellement, il ne dustinguish pas entre l'État et le comportement du tout, à la fois traiter de façon uniforme comme « caractéristiques ». Les objets sont juste des caractéristiques définit clumpled pour minimiser Dans l'ensemble dépendance.

Dans d'autres domaines, orienté objet n'est pas la meilleure approche. Il existe différents paradigmes linguistiques pour des problèmes différents. Les développeurs expérimentés savent, et sont prêts à utiliser quelle langue est la plus proche du domaine.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow