** Examen effectué **
Depuis un an, je l'ai mis à jour pour que l'explication soit la plus polie possible sans changer l'essence du contenu.
Vingt ans se sont écoulés depuis le début de l'orientation objet par Java. Je pense que l'on peut dire qu'elle a pénétré dans le domaine du développement de systèmes. Cependant, bien que le langage Java lui-même soit clair, je pense que beaucoup de gens ne sont toujours pas clairs sur l'orientation des objets. En premier lieu, l'orientation objet consistait à saisir le monde de la zone à problèmes du point de vue des «choses» et à laisser ces «choses» s'envoyer des messages pour faire fonctionner le système. Il est facile de comprendre s'il s'agit d'un objet visible, mais il est devenu ambigu lorsqu'il s'agissait d'un objet conceptuel ou abstrait, ce qui a contribué à la confusion. En outre, le fait que les explications et les introductions étaient souvent différentes des objets réels augmentait également l'ambiguïté et la difficulté à comprendre, et prêtait à confusion. Et, de manière plus réaliste, il était plus approprié d'appeler et d'utiliser l'explication de l'envoi d'un message pour le faire fonctionner. Donc, sur la base des progrès réalisés jusqu'à présent, j'aimerais revenir en arrière et comprendre à nouveau l'orientation des objets. Veuillez noter que la description suivante peut être basée sur une subjectivité personnelle. Veuillez vous référer à la brève explication dans la partie arrière pour les mots et expressions spécifiques à l'orientation de l'objet utilisés dans le texte.
Étant donné que l'orientation objet est basée sur les perceptions et les idées (concepts) humaines en premier lieu, il n'est pas possible de déterminer une réponse claire et correcte. Si vous ne comprenez pas pleinement cette prémisse, vous serez dans une situation où vous ne pourrez pas prendre diverses décisions. En conclusion, l'orientation objet était simplement l'une des méthodes d'organisation, de classification et de structuration des groupes de données et des groupes d'opérations (groupes de traitement). Eh bien, il s'agit simplement d'organiser, de classer et de composer.
Je voudrais expliquer les bases de l'orientation objet (ce que c'était) avec un exemple. (Pour ceux qui le sont maintenant, vous pouvez passer dans la gamme de ☆ d'ici à ☆ à ici ☆.) --- ☆ D'ici ☆ --- Il y en a beaucoup sur le net, mais dans un souci de clarté, je vais vous expliquer ici en me basant sur un exemple simple. Un exemple est la création d'un plat magnifique, avec les étapes suivantes:
Si vous réfléchissez bien au point 4, vous pouvez avoir des problèmes et des questions. (1) Comment collectez-vous les matériaux (données) et les outils (opérations)? Ceci est décidé en analysant à partir d'un grand nombre de recettes et en déterminant le type de matériaux et d'outils nécessaires. J'ai créé une boîte de réorganisation à l'avance, je lui ai donné un nom qui montre ce que j'ai mis et l'ai noté. Je vais mettre une étiquette dessus. (2) Combien d'organisateurs faites-vous? C'est le genre de chose que le cuisinier vérifie les choses autour de lui et écoute les opinions des autres cuisiniers. Je déciderai en essayant de m'organiser. S'il y en a trop, il sera difficile de classer, et s'il y en a trop peu, il ne sera pas possible de classer correctement. En outre, en gros, une cuisson (un type) est gérée par une boîte de rangement. (3) Dans quelle boîte de réorganisation dois-je mettre? C'est naturel, ・ Dans quelle boîte de rangement dois-je mettre cet article (matériel et outils)? ・ Étant donné que j'ai fabriqué plusieurs boîtes du même type, dois-je les stocker dans une boîte de tri? Une telle chose est considérée comme un problème. Naturellement, la méthode d'organisation diffère entre les groupes et les cuisiniers. Bien sûr, il n'est pas possible de décider de la définition selon laquelle cette chose est toujours mise dans cette boîte de réarrangement parmi les cuisiniers du Japon ne peux pas. Est-ce que c'est comme ça en tant que cuisinier? N'est-ce pas une manière réaliste d'organiser les choses? Cependant, c'est gênant et inutile quand un chef qui donne une conférence et impose une méthode d'aménagement détaillée sort. Le temps sera perdu. Après tout, c'est une technique d'organisation. Il est décidé qu'il vaut mieux s'en débarrasser et commencer à cuisiner avant qu'il ne gâche est. (4) Quels sont les jugements et les critères pour les mettre dans la boîte de réorganisation? Mettez les outils étroitement liés au matériau dans le même organiseur. Vous pouvez mettre plusieurs matériaux et outils. Vous pouvez mettre plus d'organisateurs dans l'organisateur. Vous pouvez mettre un formulaire de demande pour une autre boîte de réorganisation dans la boîte de réorganisation. (5) Comment organiser et cuisiner? Le cuisinier organisera et cuisinera. Le chef cuisine en utilisant les ingrédients et les outils de l'organisateur. Si vous avez besoin de cuisiner des ingrédients avec des attributs légèrement différents, utilisez les outils dans une autre boîte de rangement à l'intérieur. Il est également possible de l'utiliser. Et enfin, le plat fini est terminé. Nous le ferons en groupe pour compléter les magnifiques plats. --- ☆ Jusqu'ici ☆ ---
(6) Pour résumer Rassembler les mots, orienté objet est -Identifier les groupes de données et les groupes d'opérations nécessaires (groupes de traitement) à partir de l'expérience, des connaissances, des documents, etc. -Organiser, classer et structurer les groupes de données et les groupes d'opérations (groupes de traitement). ・ Pour organiser, classer et structurer, des données (matériaux) et des opérations (outils) étroitement liées à la classe définie (boîte d'organisation) sont utilisées. Attribuer et exécuter. C'était tout.
Dans l'explication ci-dessus, l'une des différences par rapport aux méthodes de développement (et programmes) jusqu'à ce point est qu'une classe est créée. Je voudrais expliquer un peu cette classe (boîte d'organisation). Une classe est une unité de base (boîte d'organisation) d'un programme Java qui contient des groupes de données (matériaux) et des groupes d'opérations (outils) associés. Pour donner un exemple, par exemple, si vous pensez à une boîte (classe) de réorganisation appelée "spaghetti", Peperoncino, sauce à la viande, bolonese, pescatore, arabita, Amatrichana, Carbonara, Alfred, Génois, Trapanais, Spaghetti napolitain, Tarako, Spaghetti Mentaiko, ... Vous pouvez insérer du matériel et des outils liés aux spaghettis. Vous voudrez peut-être placer les boîtes de tri pour chaque type, comme la sauce à l'huile, la sauce tomate, la sauce à la crème et la sauce au basilic dans la boîte de tri des spaghettis. S'il s'agit d'une sauce à l'huile, mettez le Peperoncino, s'il s'agit d'une sauce tomate, mettez la sauce à la viande, les ingrédients bolonais et les outils dans une boîte de tri par type. Et gardez à l'esprit que les "spaghettis" ne sont pas toujours en classe. Compte tenu de la classe des «aliments», il est possible de juger que les spaghettis sont un matériau (données). De plus, Peperoncino n'est pas un matériau (données), mais peut devenir une boîte (classe) de réarrangement compte tenu des garnitures. En d'autres termes, l'organisation et la classification différeront selon le type de problème envisagé sous quel point de vue. Bien sûr, cela dépend de la personne. Par conséquent, quelle que soit la classe que vous définissez, elle ne peut pas être évaluée comme correcte par tout le monde et elle est toujours ambiguë. Cette partie est relativement source de discordances de jugement et de reconnaissance, et plus il y a de personnes impliquées, plus cela devient confus. Il n'est pas possible de déterminer quelle est la bonne réponse, donc s'il n'y a pas d'erreur, il vaut mieux passer à la suivante. Et vous devez éviter de créer des classes extensibles qui ne sont pas spécifiquement requises. Cela ne fait qu'ajouter à l'ambiguïté.
Je pense que j'ai pu saisir le contour de l'orientation de l'objet. Ensuite, j'aimerais changer ma perspective sur cette fonctionnalité et approfondir ma compréhension. Les fonctionnalités orientées objet incluent l'instanciation et les trois principes (encapsulation, héritage et polymorphisme). En raison de ces caractéristiques (1) Prise en charge du traitement multiple simultané en matérialisant / incarnant (instanciant) à partir d'un concept (classe). (2) Organisez le même contenu d'implémentation en un seul endroit sans les décrire à plusieurs endroits. (3) Cachez autant que possible l'instance réelle (objet) pour améliorer son indépendance. On dit que cela peut être réalisé.
(** À propos de l'instanciation **) Alors tout d'abord, pourquoi avons-nous besoin d'une instanciation? Pour faire simple, l'instanciation signifie faire une copie de clonage de la classe et définir les valeurs dans les variables membres. L'instanciation est généralement effectuée lors de l'utilisation d'un environnement multithread (traitement multiple simultané) ou de l'héritage / polymorphisme. L'héritage et le polymorphisme seront décrits plus loin, et tout d'abord, l'instanciation dans un environnement multithread et un environnement in-thread sera décrite ci-dessous. Dans un environnement multi-thread, le même traitement (les données sont différentes) peut être effectué en même temps, ainsi la classe est matérialisée et incarnée (instanciée), et le même type d'objet contenant des données différentes est généré et traité pour chaque thread. Est commun. Cette méthode permet à chaque thread de traiter les données d'intérêt rapidement et de manière appropriée. Cependant, l'instanciation n'est pas toujours requise dans un environnement multithread, et il n'y a pas besoin d'instanciation si l'existence d'une classe est suffisante. En fait, les bibliothèques et autres ne nécessitent pas d'instanciation partielle significative à l'aide de méthodes statiques.
D'un autre côté, il peut y avoir plusieurs objets instanciés de la même classe dans le même thread en même temps. À titre d'exemple typique, vous souhaiterez peut-être effectuer un traitement en utilisant les données d'objet pour chaque objet (généralement ligne par ligne) générées en fonction des résultats de la recherche. Exemple: calculez le montant total de chaque article de vente. Dans ce cas, il est naturel que la classe de vente la plus élevée puisse être utilisée tant que le montant total est calculé. En d'autres termes, la nécessité de créer les objets multiples correspondants n'est pas toujours essentielle. Il existe deux types de tels objets, les classes d'utilisateurs et les collections (List, Map, etc.), et les classes d'utilisateurs incluent celle d'origine qui inclut la méthode de traitement réelle et celle qui n'en contient pas (Bean, DTO: DataTransferObject, VO, etc.). : ValueObject) Il existe deux types. Du point de vue du type à utiliser, dans le cas du traitement pour modifier l'état des données de détail des ventes (DB) (modifier la valeur), il est toujours préférable d'effectuer le traitement dans la classe de détail des ventes (classe d'utilisateurs). Est la bonne perspective. En d'autres termes, s'il y a des données à conserver (pas des données temporaires) et qu'il y a un processus pour changer sa valeur, il est préférable de les traiter avec la classe d'utilisateur qui conserve les données (créer une telle classe). Devrait être). Cependant, s'il n'y a pas de traitement spécial pour changer la valeur, il semble que des classes telles que les collections, les beans, les DTO et les VO peuvent être utilisées (le besoin d'encapsulation est faible). En outre, dans le cas où le résultat de la recherche est renvoyé sous forme de liste de chaînes de caractères, il est préférable de transmettre la liste de chaînes de caractères (collection) sans ressaisir le groupe d'objets.
De ce qui précède, on peut dire qu'il est possible (efficace) de concevoir une classe d'utilisateurs dans son ensemble, de l'instancier et de la traiter dans plusieurs processus simultanés, mais ce n'est pas toujours essentiel, y compris l'environnement in-thread, et il est flexible. Cela signifie que nous devons nous en occuper. En d'autres termes, il s'agit d'une instance de la fonction la plus basique en orientation objet (y compris la POO), mais compte tenu de la situation actuelle, il semble que ce n'est pas aussi nécessaire que le slogan à ce moment-là. Cependant, je pense que les caractéristiques de l'instanciation ont contribué dans une certaine mesure à convaincre la nécessité et la validité de l'orientation objet.
(** À propos des trois principes **)
Ensuite, je voudrais expliquer les trois principes d'encapsulation, d'héritage et de polymorphisme.
Tout d'abord, je vais expliquer chaque terme.
Ensuite, je voudrais évaluer et expliquer du point de vue de l'utilité de ces trois principes, sur la base de mon expérience jusqu'à présent. (1) Rendre le programme plus indépendant et plus concis en utilisant ces trois principes. Je pense qu'il est certain que vous pouvez le faire. (2) Ces trois principes sont plus efficaces, notamment dans le développement des fonctions de base (cadre et parties équivalentes de fonction commune). Il semble que. (3) Développement en douceur du flux de l'analyse orientée objet / organisation de conception / classification à la mise en œuvre On peut dire que c'est un mécanisme qui peut attendre. (4) Mettre en place dans la mesure nécessaire en utilisant un mécanisme comme les trois principes sans être lié par le mot orienté objet Il semble réaliste et efficace à mesurer et à mettre en œuvre. (5) Cependant, ces mécanismes sont utilisés plus que nécessaire pour compliquer la conception et la structure du programme. Veuillez noter que la productivité peut diminuer. Comme mentionné ci-dessus, ces trois principes ne sont pas uniquement orientés objet Java, ils peuvent être mis en pratique dans de nombreux autres environnements de développement.
Enfin, je voudrais vous expliquer une comparaison avec le module dont on a parfois parlé. Fondamentalement, je ne pense pas que ce que vous pouvez faire (traiter) avec des "objets" ne puisse pas être fait avec des "fonctions" / "modules". Bien entendu, on suppose que la longueur du programme, la longueur de la mémoire, la vitesse de traitement, etc. ne sont pas prises en considération. Une des caractéristiques des "objets" est qu'ils peuvent exister en même temps, mais d'un autre côté, les "fonctions" et les "modules" ne peuvent pas avoir plusieurs en même temps. Cependant, cela peut également être pratiquement possible avec des «fonctions» et des «modules» en incorporant des fonctions qui peuvent réaliser plusieurs processus. En termes de slogan, je pense que c'est plus comme "... peut être réalisé relativement facilement d'une manière orientée objet" plutôt que "... peut être réalisé parce qu'il est orienté objet." Je pense que le slogan un peu net était également la cause de la confusion.
Après l'explication ci-dessus, l'orientation objet était-elle vraiment nécessaire? Personnellement, il semble que l'orientation objet ait peu de nouvelles fonctionnalités sans alternatives au niveau de base, et je ne pense pas qu'elle était essentielle de ce point de vue, mais elle est efficace et produite par son apparence. Je pense qu'on peut dire qu'il y a eu un certain effet dans l'amélioration de la sexualité et de la qualité. Par conséquent, il semble qu'un certain effet peut être attendu à condition qu'il soit adopté en faisant attention aux précautions d'utilisation décrites plus loin.
A cette époque, j'ai souvent entendu dire que le développement orienté objet avait échoué. Alors, que signifiait exactement le développement en premier lieu avec l'orientation objet? Et qu'est-ce qui a mal tourné suite à ce que nous avons fait? At-il échoué parce qu'il a adopté le langage Java? Le langage Java est toujours à l'avant-garde du domaine, et je ne pense pas qu'il y ait eu quoi que ce soit de fatal. Je soupçonne que la plupart des causes générales du développement de système l'étaient. Les causes de l'échec (en termes de coût, de délai, de qualité) sont les suivantes (du point de vue de l'entrepreneur / développeur). ・ Je n'ai pas fait une estimation appropriée. J'ai facilement baissé le prix pour recevoir une commande. Il s'est concentré sur le prix et a minimisé les perspectives de la vie réelle telles que l'expérience, la technologie et la structure. ・ Faible capacité à déterminer les spécifications. Lors du développement, un grand nombre de spécifications doivent être décidées de manière flexible. Étant donné que la capacité et l'autorité du donneur d'ordre et du côté du développement étaient trop faibles, il n'était pas possible de prendre des décisions et des jugements appropriés. a gagné. ・ Faible capacité de communication La communication entre le côté commande et le côté développement, l'intérieur du côté commande et l'intérieur du côté développeur est médiocre. Quoi qu'il en soit, il a une attitude ferme pour éviter les responsabilités et transmettre le travail et la responsabilité aux autres. ・ Faible volonté de réussir. Le côté commande et le côté développement ont de toute façon une faible intention de réussir. Cette tendance est particulièrement vraie lorsqu'il y a beaucoup de travailleurs à temps (parce que les employés d'autres entreprises ne sont pas responsables). Devenir plus fort. ・ Inexpérimenté. Le nombre de personnes expérimentées qui ont besoin d'une technologie de plate-forme de développement, d'un langage, d'un middleware, etc. est faible. De nombreux membres n'ont aucune connaissance des domaines. Je pense qu'il est possible que le mot «échec» ne puisse être utilisé de manière orientée objet qu'après avoir effacé ces derniers. Alors, quelles sont les causes des échecs orientés objet? ・ Beaucoup de temps est consacré aux discussions sur l'orientation des objets, et non aux spécifications d'origine en analyse et conception. J'étais désolé. · Passez beaucoup de temps à créer une documentation orientée objet dans l'analyse et la conception J'attendais. ・ Parce que la granularité de la classe était inutilement petite et que la structure était compliquée et profonde, il a fallu plus de temps pour se développer. Il avait faim. ・ De nombreux membres n'avaient presque jamais expérimenté la POO en premier lieu. ・ J'ai essayé de pratiquer une méthodologie de développement avec peu d'expérience. Est-ce un tel endroit? Il semble qu'une telle chose n'était pas essentielle et pourrait être évitée relativement facilement. Comme mentionné ci-dessus, la discussion sur l'orientation des objets aurait dû être réduite au minimum et beaucoup de temps aurait dû être consacré à la spécification d'origine. On aurait dû considérer qu'une orientation d'objet inutilement dépendante ou biaisée n'est pas bonne pour les performances de coût.
Ensuite, je voudrais revenir sur la méthodologie de développement sous l'angle de l'échec. Comme c'est le cas aujourd'hui, diverses méthodologies de développement ont été proposées à l'époque. Ces diverses méthodologies de développement sont devenues un sujet brûlant et ont été reconnues comme faisant partie de l'orientation objet, ce qui a également contribué à la confusion sur l'orientation objet. Il s'agissait principalement d'une proposition de passer du type cascade conventionnel au type italation (y compris le type agile). Donc, ce n'est pas que le type italation est devenu courant maintenant, mais les bases sont toujours le type cascade. Il semble que cette méthodologie de développement mixte ait contribué à l'histoire de l'échec orienté objet. Je pense qu'il était nécessaire de traiter les méthodologies orientées objet et de développement essentiellement séparément. Je pense que de nombreux ingénieurs et clients ont grandement contribué aux éditeurs de logiciels pendant cette période (rires).
Alors, que devons-nous faire avec la documentation? Les documents spécifiques à l'orientation des objets comprennent: Diagramme de modèle conceptuel, diagramme de cas d'utilisation, description de cas d'utilisation, diagramme de package, diagramme de classes d'analyse, Diagramme de séquence d'analyse, diagramme de classe de conception, diagramme de séquence de conception, diagramme d'activité de conception, etc. Il ne fait aucun doute qu'il est douteux du point de vue de la rentabilité de créer un tel document de manière licite. Il n'est peut-être pas possible d'écrire en premier lieu dans un développement à grande échelle. Bien que les performances des récents outils de création de diagrammes UML se soient améliorées, je pense qu'il est difficile de dessiner des diagrammes sur des systèmes à grande échelle. Il serait approprié de viser la création de documents qui peuvent décrire les éléments nécessaires dans une quantité appropriée, peuvent être utilisés efficacement, peuvent facilement répondre aux changements, ne nécessitent pas de nouveaux outils et peuvent être utilisés comme livrable. Cependant, dans le développement de fonctions communes de base (frameworks au niveau de l'application qui ne sont pas des middlewares), il semble efficace de créer des diagrammes de classes en tant que documents temporaires. Il est certain qu'il est avantageux en termes de temps et d'évolution d'organiser les documents orientés objet au format tableau Excel, etc., au lieu d'utiliser des chiffres comme UML. De plus, je pense qu'il a l'avantage de pouvoir instruire avec précision le contenu nécessaire.
L'écran initial doit être créé avec HTML ou des outils de conception d'écran, etc., puis un prototype doit être créé et confirmé sans montage, y compris les transitions d'écran, avant le processus de montage, et utilisé dans le processus de montage.
L'une des raisons du développement orienté objet était que «c'est parce que nous pouvons réagir avec souplesse aux changements», a été expliqué plus comme à l'époque. Les changements ont été appelés hotspots. Bien entendu, il sera possible de répondre à cette exigence si l'ensemble de la mise en œuvre est consciemment mis en œuvre par la POO. Cependant, si vous y réfléchissez, il y a des millions et des dizaines de millions d'étapes partout dans le programme. Si vous introduisez un critère qui est "hautement susceptible de changer", vous rencontrerez le thème de la clarification et de l'incarnation de ce critère. Un autre problème est de savoir qui décide s'il est élevé ou faible et qui en a le coût. Il peut être possible de prendre certains risques dans le travail de développement s'il y a une perspective que le travail d'opération puisse être confié sans faute, mais une telle forme est devenue rare ces dernières années.
De plus, il est inutile et irréaliste de faire une POO déraisonnable en devinant sans clarifier quel type de changement se produira. Par conséquent, afin de répondre aux changements, il est nécessaire de prendre des mesures telles que la clarification et la détermination des spécifications de changement, la conception, la programmation et les tests à l'avance. En d'autres termes, nous devons construire un mécanisme capable de répondre aux changements. Je suis conscient que ce n'est pas tant que les fonctionnalités orientées objet exercent une grande productivité et une grande importance dans cette partie de construction de mécanisme. Dans l'ensemble, ce n'est pas très différent des autres méthodes et moyens de développement. Après tout, comme mentionné ci-dessus, il est préférable de le spécifier dans les spécifications requises et de le réaliser dans un environnement où le coût et la période peuvent être enregistrés.
J'ai décrit ce que j'ai trouvé en regardant en arrière sur le passé, mais enfin, à partir des résultats de ces réflexions, j'ai énuméré les points à prendre en compte lors de la pratique de l'orientation objet dans le futur. Veuillez vous y référer.
·concept Un concept est un mot qui signifie «caractéristiques communes à toutes choses». Lorsqu'il y a plusieurs choses qui ont des propriétés communes, elles sont considérées comme du même type en raison des points communs. Image formée par. Exemple: concept de chat (image de chat), concept de voiture (image de voiture), etc. D'un point de vue différent de la classification, on peut dire qu'il s'agit d'une classification supérieure. ·passer outre Fait référence à la redéfinition d'une méthode définie dans une classe parente dans une classe enfant. ·Surcharge Méthodes avec le même nom de méthode mais différents types d'arguments, nombres et ordre dans la même classe Se réfère à la définition de multiple.