J'ai récemment eu un débat avec un collègue qui n'est pas un fan de OOP . Ce qu'il a attiré mon attention était ce qu'il a dit:
"Quel est le point de faire mon codage dans des objets? Si c'est une réutilisation, je peux simplement créer une bibliothèque et appeler les fonctions dont j'ai besoin pour la tâche est à portée de main. Dois-je avoir besoin de ces concepts de polymorphisme, héritage, interfaces, motifs ou quoi que ce soit? "
Nous sommes dans une petite entreprise développant de petits projets pour les sites de commerce électronique et l'immobilier.
Comment puis-je profiter de OOP dans une configuration "quotidienne et réelle"? OU OOP était-il vraiment destiné à résoudre des problèmes complexes et non destinés au développement "quotidien"?
13 Réponses :
Plus que d'obtenir quelque chose à travailler, le point de votre ami, une conception OO bien conçue est plus facile à comprendre, à suivre, à développer et à mettre en œuvre. Il est tellement plus facile, par exemple, de déléguer des travaux similaires ou de contenir des données qui devraient rester ensemble (oui même une structure C est un objet).
Je suis d'accord, mais je ne pense pas que cela aide à répondre à la question de quelqu'un sur la façon dont OOP est "meilleur". Une application C bien conçue offre la même chose. Une structure C n'est pas un objet. Une structure C ++ est un objet.
Hmm Une structure C est un objet autant qu'une structure C ++. En fait, si une structure C ++ est un objet que vous admettez, pourquoi aucune structure C?
La mesure dans laquelle une conception OO ou non OO présente ces caractéristiques est directement proportionnelle à la compétence du concepteur. Pour le problème des structures: en C, je ne peux pas hériter d'une autre structure ni de morphère. Je ne peux pas intégrer la logique fonctionnelle dans la structure et surcharger le comportement dans la prochaine génération de ladite structure. En C ++, je peux faire tout cela parce que le travail clé de la structure est une façade pour créer une classe.
Ne me confondez pas avec quelqu'un qui n'aime pas OOP. C'est (presque) le seul paradigme que j'utilise. Je trouve juste la plupart des arguments sur cette question qui manque.
Il n'est donc pas que une structure est un objet ou non, mais votre point est que quelque chose soit un objet, il devrait prendre en charge la logique fonctionnelle qui devrait pouvoir être remplacée! Je suis complètement en désaccord parce qu'un objet sans fonctionnalité n'est toujours pas un objet par le simple fait qu'il détient un groupe d'éléments connexes. Maintenant, même si vous optez par Struct Syntaxe, vous pourriez certainement avoir des pointeurs de fonction comme les membres de données de Struct qui fournissent cette fonctionnalité.
Non simplement remplacer la fonctionnalité, mais être capable de tenir simultanément la fonctionnalité des deux types A et B à l'aide des mêmes interfaces de code. C structs ne supporte pas un tel mécanisme. Ce mécanisme est ce qui crée un "objet" contre un "record"
Eh bien, je suis sûr que beaucoup de gens donneront beaucoup plus de réponses académiquement correctement correctement, mais voici ma prise sur quelques-uns des avantages les plus précieux:
Cette réponse serait tellement meilleure si vous développeriez sur les deux premiers points et supprimez simplement le troisième.
Je vois cette réponse comme une autre qui répertorie les points de bullet (comme vous l'avez fait!) Mais ne donne aucune indication sur la raison pour laquelle c'est "mieux".
Mon point de vue personnellement: Contexte
Lorsque vous programmez dans OOP, vous avez une plus grande sensibilisation au contexte. Cela vous aide à organiser le code de manière à ce qu'il soit plus facile de comprendre car le monde réel est également orienté objet.
Oui, exactement. Les humains créent des choses comme des modèles de nature. Oop est plus comme la vraie vie; choses sont prises séparément.
Je suis d'accord. C'était comme ça que mon conférencier l'a expliqué pendant l'UNI. Il a dit qu'il aide à modéliser des objets sur quelque chose de monde réel (ou aussi près de) car les objets du monde réel ne changent pas beaucoup et il est plus facile de visualiser votre esprit.
Je ne pense pas que OOP est comme une vraie vie du tout. Je pense que c'est une tentative de simplifier et de résumer la vie réelle aux concepts assez simples pour que nous puissions comprendre et manipuler. Pensez à la modélisation avec précision dans OOP une chose aussi simple que «un stylo écrivant sur un morceau de papier».
Il s'agit d'un argument classique en faveur de l'OOP, mais je ne pense pas que cela aide le programmeur C irrépensent à comprendre les avantages lorsque OUP est approprié. Je ne vais pas descendre, mais c'est une réponse féculale délicieuse et il n'y a vraiment pas grand chose à continuer.
@San jacinto je suis d'accord. La capacité de capturer le contexte fait partie de ce qui rend le oop si puissant, mais simplement pointant sur ce fait, ce n'est pas vraiment un argument puissant en faveur de l'OPO. Vous avez besoin d'exemples concrets de la manière dont l'ajout de contexte à vos programmes vous fera gagner du temps, de vous faire de l'argent et de blanchir vos dents.
Honnêtement, je pense que ce n'est pas possible de convaincre un programmeur procédural durement de la compréhension des avantages de OOP, c'est quelque chose que vous devez faire l'expérience de la première main: o)
Les bonnes choses sur OOP viennent de lier un ensemble de données à un ensemble de comportements.
Donc, si vous devez effectuer de nombreuses opérations connexes sur un ensemble de données associé, vous pouvez écrire de nombreuses fonctions qui fonctionnent sur une structure ou vous pouvez utiliser un objet.
Les objets vous donnent une certaine réutilisation de code aide sous forme d'héritage.
IME, il est plus facile de travailler avec un objet avec un ensemble connu d'attributs et de méthodes qu'il consiste à conserver un ensemble de structs complexes et aux fonctions qui les utilisent.
Certaines personnes iront sur l'héritage et le polymorphisme. Celles-ci sont précieuses, mais la valeur réelle dans OOP (à mon avis) provient de la manière Nice, il encapsule et associe des données avec des comportements.
Si vous utilisez OOP sur vos projets? Cela dépend de la façon dont votre langue prend en charge OOP. Cela dépend des types de problèmes que vous devez résoudre.
Mais, si vous faites de petits sites Web, vous parlez toujours de suffisamment de complexité que j'utiliserais la conception de l'OOP donnée un soutien approprié dans la langue de développement.
Je conviens que la syntaxe est plus propre lorsque vous attachez les données directement aux actions, mais pour une personne qui ne comprend pas OOP, ce n'est que du sucre syntaxique.
Le sucre syntaxique peut être très nutritif. Tout ce que nous faisons dans une langue de haut niveau est le sucre sur l'assembleur. Chaque fois que je dois travailler dans la langue d'assemblage, ce sucre manque très, beaucoup. Donc, j'ai du mal à rejeter toute construction de langue qui améliore la productivité en tant que "juste sucre syntaxique". IMO, tout développeur de logiciel qui ne comprend pas au moins les trois principaux styles de programmation (impératif, fonctionnel et OOP) doit sortir de son cul et frapper les livres. Comprendre ces méthodes fournit des concepts essentiellement de manière efficace pour la décomposer des problèmes dans n'importe quelle langue ou paradigme.
Regardez l'utilisation de modèles de conception et vous verrez l'utilité de OOP. Il ne s'agit pas seulement d'encapsulation et de réutilisation, mais d'extensibilité et de maintenabilité. Ce sont les interfaces qui rendent les choses puissantes.
Quelques exemples:
Mise en œuvre d'un flux (motif de décorateur) sans objets est difficile
Ajout d'une nouvelle opération à un système existant tel qu'un nouveau type de cryptage (modèle de stratégie) peut être difficile sans objets.
regarder le chemin postgreSQL est mis en œuvre par rapport à votre façon de votre livre de base de données indique une base de données devrait être mis en œuvre et vous verrez un grand différence. Le livre va suggérer Objets de nœud pour chaque opérateur. Postgres utilise des tables myriades et macros pour essayer d'imiter ces nœuds. C'est beaucoup moins jolie et beaucoup plus difficile de s'étendre à cause de cela.
La liste continue.
Des motifs de conception, en particulier ceux populaires par le livre GOF, existent en grande partie en raison des limitations de C ++ et de Java, en particulier leur nature statique. Le schéma de stratégie, pour une, est évité avec les procédures de première classe
Je dois être en désaccord. Je sais que c'est une pensée commune de nos jours, mais elle est historiquement inexacte. La plupart des motifs GOF sont originaires de Smalltalk où des fonctions sont de première classe. Il est vrai que vous pouvez prendre des fonctions et des fermetures de la 1re classe et obtenez de nombreux avantages que OO pour un modèle de stratégie, mais cela ne fait pas une mauvaise idée de OO plus que OO de programmation fonctionnelle une mauvaise idée. Ils sont deux implémentations de la même idée.
Le sentiment plus courant est que les modèles de conception de GOF "évaporent" dans de telles langues. Le "modèle d'appel de procédure" est l'exemple que je préfère citer - avant l'avènement d'Algol, vous deviez passer par de nombreux cerceaux pour mettre en œuvre le concept de procédure récursive. Maintenant, en C ++, le modèle d'appel de procédure est simple. Je viens d'écrire "FOO (bar)", et magiquement mes habitants sont sauvegardés, la barre est poussée sur la pile, etc. De même, le motif d'usine disparaît dans "FOO (bar)" en Python, comme la création d'objets et les appels de fonctions sont unifiés. .
Tous les paradigmes de programmation ont le même objectif: cacher une complexité inutile.
Certains problèmes sont facilement résolus avec un paradigme impératif, comme l'utilisation de votre ami. D'autres problèmes sont facilement résolus avec un paradigme orienté objet. Il y a beaucoup d'autres paradigmes . Les principales (programmation logique, programmation fonctionnelle et programmation impérative) sont tous équivalents les uns aux autres; La programmation orientée objet est généralement considérée comme une extension à la programmation impérative.
La programmation orientée objet est mieux utilisée lorsque le programmeur modélise les éléments similaires, mais pas les mêmes. Un paradigme impératif mettrait les différents types de modèles dans une seule fonction. Un paradigme orienté objet sépare les différents types de modèles en différentes méthodes sur des objets associés.
Votre collègue semble être bloqué dans un paradigme. Bonne chance.
La conception de la technologie et de la méthodologie de la conception. Les bonnes conceptions ont tendance à incorporer des directeurs universels de gestion de la complexité, tels que la loi de Demeter, qui est au cœur de ce que les fonctionnalités de la langue de l'OO s'efforcent de codifier.
Un bon design n'est pas dépendant de l'utilisation de fonctionnalités de langue spécifiques de OO, bien qu'elle soit typiquement dans les meilleurs intérêts à les utiliser.
Non seulement est-il
Vous trouverez de plus amples informations à ce sujet regardant: - Java: Mise en veille prolongée - Dot Net: Entity Framework p>
Voir même comment LINQ (Visual Studio) peut vous rendre la vie beaucoup plus facile de programmation p>
Peut-être il est même amusant de démontrer avec une petite démo: p>
.PS. J'ai essayé de l'écrire d'une manière PSEUDO:) p>
Code de vous appeler: io.file.save (objectsCollection.ourFunctionForSaving ()) p>
classe objectsCollection p>
ourFunctionForSaving fonction () As String p>
string _Objects p>
for each _Object in objectsCollection
Objects &= _Object & "-"
end for
Environ 1994 J'essayais de donner un sens à OOP et en C ++ en même temps, et je me suis retrouvé frustré, même si je pouvais comprendre en principe quelle était la valeur de l'OPO. J'étais tellement habitué de pouvoir jouer avec l'état de toute partie de l'application à partir d'autres langues (principalement des langues de base, de montage et de la famille Pascal-famille) qu'elle semblait avoir abandonné la productivité en faveur d'une abstraction académique. Malheureusement, mes premières rencontres avec des cadres oo comme le MFC ont rendu plus facile le piratage, mais ne fournissaient pas nécessairement beaucoup dans la voie de l'illumination.
Ce n'était que par une combinaison de persistance, une exposition à des méthodes alternatives (non-C ++) de traiter avec des objets et une analyse minutieuse du code de l'OO que 1) a fonctionné et 2) lire plus de manière cohérente et intuitive que le code procédural équivalent que j'ai commencé à l'obtenir vraiment. Et 15 ans plus tard, je suis régulièrement surpris de nouveau (à moi) des découvertes de solutions d'OO intelligentes et impressionnantes, je ne pouvais pas imaginer de faire comme soigneusement dans une approche procédurale.
J'ai traversé le même ensemble de luttes en essayant de donner un sens au paradigme de programmation fonctionnel au cours des deux dernières années. Pour paraphraser Paul Graham, lorsque vous regardez le continuum de puissance, vous voyez tout ce qui manque. Lorsque vous recherchez le continuum de puissance, vous ne voyez pas le pouvoir, vous voyez juste une étrangeté.
Je pense, afin de s'engager à faire quelque chose d'une manière différente, vous devez 1) voir quelqu'un d'étant évidemment plus productif avec des constructions plus puissantes et 2) suspendre l'incrédulité lorsque vous vous trouvez frapper un mur. Cela contribue probablement à avoir un mentor qui est au moins un peu minuscule plus loin dans leur compréhension du nouveau paradigme.
En empêchant la consommation nécessaire pour suspendre l'incrédulité, si vous voulez que quelqu'un grocser rapidement la valeur d'un modèle OO, je pense que vous pourriez faire beaucoup plus pire que de demander à quelqu'un de passer une semaine avec le livre de programmeurs pragmatiques sur les rails. Malheureusement, cela laisse beaucoup de détails sur la façon dont la magie fonctionne, mais c'est une très bonne introduction à la puissance d'un système d'abstractions OO. Si, après avoir travaillé sur ce livre, votre collègue ne voit toujours pas la valeur de OO pour une raison quelconque, il / elle peut être un cas sans espoir. Mais si elles sont prêtes à passer un peu de temps à travailler avec une approche qui travaille fortement d'OO qui travaille et les obtient de 0 à 60 plus plus vite que de faire la même chose dans une langue procédurale, il peut être d'espoir. Je pense que c'est vrai même si votre travail n'implique pas de développement Web.
Je ne suis pas si sûr que faire ressortir le "monde réel" serait autant de points de vente qu'un cadre de travail pour écrire de bonnes applications, car il s'avère que, surtout dans des langages typés statiquement comme C # et Java, 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 ont du mal à modéliser quelque chose d'aussi simple que l'abstraction géométrique de la "forme" (forme, ellipse, cercle).
La puissance de la plupart des langages de programmation se trouve dans les abstractions qu'ils sont disponibles. La programmation orientée objet fournit un système très puissant d'abstractions dans la manière dont il vous permet de gérer les relations entre des idées ou des actions connexes.
Considérez la tâche de calculer les zones pour une collecte de formes arbitraires et en expansion. Tout programmeur peut rapidement écrire des fonctions pour la zone d'un cercle, carré, triangle, ect. et stockez-les dans une bibliothèque. La difficulté vient lorsque vous essayez d'écrire un programme qui identifie et calcule la zone d'une forme arbitraire. Chaque fois que vous ajoutez un nouveau type de forme, dites un Pentagone, vous devez mettre à jour et prolonger quelque chose comme un Avec la programmation orientée objet, beaucoup de celles-ci est libre, définissez simplement une classe de forme contenant une méthode de la zone. Ensuite, cela ne comporte pas vraiment quelle forme spécifique que vous traitez au moment de l'exécution, faites simplement chaque silhouette géométrique un objet qui hérite de la forme et appelez la méthode de la zone. Le paradigme orienté objet traite les détails de si, à ce moment-là, avec cette entrée utilisateur, devons-nous calculer la zone d'un cercle, de triangle, de carré, de pentagone ou de l'option Ellipse qui a été ajoutée il y a une demi-minute. < / p>
Et si vous décidez de changer l'interface de la manière dont la fonction de la zone a été appelée? Avec la programmation orientée objet Vous ne feriez que mettre à jour la classe de forme et les modifications se propagent automatiquement à toutes les entités hérités de cette classe. Avec un système non orienté objet, vous seriez confronté à la tâche de Slogging via votre "bibliothèque de fonctions" et mettre à jour chaque interface individuelle.
En résumé, la programmation orientée objet fournit une forme d'abstraction puissante qui peut vous faire économiser du temps et des efforts en éliminant la répétition dans votre code et rationaliser les extensions et la maintenance. si ou case pour permettre à votre programme d'identifier le nouveau forme et appelez la routine de zone correcte de votre "bibliothèque de fonctions". Après un certain temps, les coûts de maintenance associés à cette approche commencent à s'empiler.
Demandez à votre ami de visualiser
Les choses comme un bouton ne font pas quelque chose seul - il faut beaucoup d'objets pour passer un appel téléphonique. De même, un moteur de voiture est constitué de l'arbre de manivelle, des pistons, des bougies d'allumage. Les concepts OOPS ont évolué de notre perception dans les processus naturels ou dans nos vies.
Le livre "Inside Com" indique le but de com en prenant de l'analogie à partir d'un jeu d'enfance d'identification des animaux en posant des questions.
Dans les domaines où l'état et le comportement sont mal alignés, l'orientation objet réduit la densité de dépendance globale (c'est-à-dire la complexité) dans ces domaines, ce qui rend les systèmes résultants moins fragiles.
C'est parce que l'essence de l'orientation de l'objet est basée sur le fait que, de manière organisationnelle, elle ne ménage pas du tout entre l'état et le comportement, traitant à la fois des "caractéristiques". Les objets ne sont que des ensembles de fonctions gravées pour minimiser globalement dépendance.
Dans d'autres domaines, l'orientation objet n'est pas la meilleure approche. Il existe différents paradigmes de langue pour différents problèmes. Les développeurs expérimentés le savent et sont disposés à utiliser quelle que soit la langue la plus proche du domaine.
Pour moi, le pouvoir de OOP ne se montre pas avant de commencer à parler d'héritage et de polymorphisme.
Si son argument pour OOP repose sur le concept d'encapsulation et d'abstraction, ce n'est pas un argument très convaincant pour moi. Je peux écrire une énorme bibliothèque et ne documenter que les interfaces que je souhaite que l'utilisateur soit au courant, ou je puisse compter sur des constructions de niveau linguistique telles que des packages à ADA pour rendre les champs privés et n'exposer que ce que je veux que je veux Exposer.
Cependant, l'avantage réel vient lorsque j'ai écrit du code dans une hiérarchie générique de sorte qu'il puisse être réutilisé plus tard de manière à ce que les mêmes interfaces de code exactes soient utilisées pour différentes fonctionnalités pour obtenir le même résultat.
Pourquoi est-ce pratique? Parce que je peux me tenir sur les épaules des géants pour accomplir ma tâche actuelle. L'idée est que je peux faire bouillir les parties d'un problème jusqu'aux pièces les plus élémentaires, les objets qui composent les objets composant ... les objets qui composent le projet. En utilisant une classe qui définit le comportement très bien dans l'affaire Général, je peux utiliser ce même code éprouvé pour créer une version plus spécifique de la même chose, puis une version plus spécifique de la même chose, puis une version encore plus spécifique. version de la même chose. La clé est que chacune de ces entités a déjà été codée et testée, et il n'est pas nécessaire de le réimplanter plus tard. Si je n'utilise pas de héritage pour cela, je finis par réimplémenter la fonctionnalité commune ou relier explicitement mon nouveau code par rapport à l'ancien code, qui fournit un scénario pour moi d'introduire des bogues de contrôle de contrôle.
Le polymorphisme est très pratique dans les cas où j'ai besoin d'obtenir une certaine fonctionnalité d'un objet, mais la même fonctionnalité est également nécessaire à partir de types similaires, mais uniques. Par exemple, à Qt, il y a l'idée d'insérer des éléments sur un modèle afin que les données puissent être affichées et que vous puissiez facilement entretenir des métadonnées pour cet objet. Sans polymorphisme, j'aurais besoin de me déranger avec beaucoup plus de détails que je ne le ferais actuellement (c'est-à-dire que je devrais mettre en œuvre les mêmes interfaces de code qui conduisent la même logique commerciale que l'élément initialement destiné à aller sur le modèle). Étant donné que la classe de base de mon objet lié à des données interagit de manière native avec le modèle, je peux plutôt insérer des métadonnées sur ce modèle sans problème. J'obtiens ce dont j'ai besoin de l'objet sans préoccupation sur ce que les besoins du modèle et le modèle obtiennent ce dont il a besoin sans préoccupation sur ce que j'ai ajouté à la classe.
Il est généralement considéré comme poli d'ajouter un commentaire indiquant pourquoi vous avez downvote.
+1: L'encapsulation et l'abstraction ont été autour pour toujours. OMI L'idée de polymorphisme est la clé unique de la puissance du style OO.
Quel est le point si je dois apprendre quelque chose de nouveau quand je pourrais être la programmation? Une petite entreprise? - Je suppose que cela signifie qu'il y aura des frictions lorsqu'il doit faire face à votre code OO ou à votre visa versa.
J'aimerais ajouter un cavalier à cette question si je peux, étant récemment sauté dans OOP. Y a-t-il quelqu'un qui a quelque chose à dire en défense des commentaires du collège de Ygam? Il serait intéressant d'entendre des avantages / contre.
UHM ... Je ne suis pas sûr que votre collègue devrait élaborer des sites Web "professionnellement" s'il ne comprend pas les mérites de OOP. Personnellement, je ne pense pas que ce soit la solution à tout, mais cela dépasse certainement n'importe quel projet de plus d'environ 200 lignes.
Peut-être que votre ami doit avoir lu cette interview (faux ??): NSBASIC.com /Newton/info/nsbasic/interview.shtml