** Überprüfung durchgeführt **
Da ein Jahr vergangen ist, habe ich es aktualisiert, damit die Erklärung so höflich wie möglich ist, ohne das Wesentliche des Inhalts zu ändern.
Zwanzig Jahre sind vergangen, seit die Objektorientierung durch Java begann. Ich denke, man kann sagen, dass es in den Bereich der Systementwicklung eingedrungen ist. Das heißt, die Java-Sprache selbst ist klar, aber ich bin sicher, dass viele Leute noch nicht ganz klar über die Objektorientierung sind. In erster Linie bestand die Objektorientierung darin, die Welt des Problembereichs vom Standpunkt der "Dinge" aus zu erfassen und diese "Dinge" einander Nachrichten senden zu lassen, um das System zu betreiben. Es ist leicht zu verstehen, ob es sich um ein sichtbares Objekt handelt, aber es wurde mehrdeutig, wenn es um ein konzeptuelles oder abstraktes Objekt ging, was zur Verwirrung beitrug. Darüber hinaus erhöhte die Tatsache, dass sich die Erklärungen und Einführungen häufig von den tatsächlichen Objekten unterschieden, die Mehrdeutigkeit und das Verständnis und war verwirrend. Realistischer war es angemessener, die Erklärung zum Senden einer Nachricht anzurufen und zu verwenden, damit sie funktioniert. Aufgrund der bisherigen Fortschritte möchte ich noch einmal zurückblicken und die Objektorientierung verstehen. Bitte beachten Sie, dass die folgende Beschreibung auf persönlicher Subjektivität beruhen kann. In der kurzen Erläuterung im hinteren Teil finden Sie die Wörter und Ausdrücke, die für die im Text verwendete Objektorientierung spezifisch sind.
Da die Objektorientierung in erster Linie auf menschlichen Wahrnehmungen und Ideen (Konzepten) basiert, ist es nicht möglich, eine eindeutige richtige Antwort zu finden. Wenn Sie diese Prämisse nicht vollständig verstehen, befinden Sie sich in einer Situation, in der Sie nicht verschiedene Entscheidungen treffen können. Zusammenfassend war die Objektorientierung einfach eine der Methoden zum Organisieren, Klassifizieren und Strukturieren von Datengruppen und Operationsgruppen (Verarbeitungsgruppen). Nun, es geht nur darum, zu organisieren, zu klassifizieren und zu komponieren.
Ich möchte die Grundlagen der Objektorientierung (was es war) anhand eines Beispiels erläutern. (Für diejenigen, die jetzt sind, können Sie im Bereich von ☆ von hier nach ☆ nach hier pass übergeben.) --- ☆ Von hier ☆ --- Es gibt viele im Netz, aber der Klarheit halber werde ich dies hier anhand eines einfachen Beispiels erläutern. Ein Beispiel ist das Erstellen eines großartigen Gerichts mit den folgenden Schritten:
Wenn Sie sorgfältig über Punkt 4 nachdenken, haben Sie möglicherweise einige Probleme und Fragen. (1) Wie sammeln Sie Materialien (Daten) und Werkzeuge (Operationen)? Dies wird entschieden, indem anhand einer Vielzahl von Rezepten analysiert wird, welche Materialien und Werkzeuge benötigt werden. Ich habe im Voraus eine Neuanordnungsbox erstellt, ihr einen Namen gegeben, der zeigt, was ich eingegeben habe, und sie aufgeschrieben. Ich werde ein Etikett darauf setzen. (2) Wie viele Organisatoren machen Sie? Dies ist eine Art Sache, bei der der Koch die Dinge um sich herum überprüft und auf die Meinungen anderer Köche hört. Ich werde mich entscheiden, indem ich versuche, mich zu organisieren. Wenn es zu viele gibt, ist es schwierig zu klassifizieren, und wenn es zu wenige gibt, ist es nicht möglich, richtig zu klassifizieren. Grundsätzlich wird ein Garvorgang (eine Art) von einer Organisationsbox erledigt. (3) Welche Umordnungsbox soll ich einsetzen? Das ist natürlich, ・ In welche Organisationsbox soll ich diesen Gegenstand (Materialien und Werkzeuge) legen? ・ Soll ich mehrere Kartons desselben Typs in einer Sortierbox aufbewahren, da ich sie hergestellt habe? So etwas wird als Problem angenommen. Natürlich unterscheidet sich die Organisationsmethode zwischen Gruppen und Köchen. Natürlich ist es nicht möglich, die Definition zu bestimmen, dass dieses Ding unter Köchen in ganz Japan immer in diese Umordnungsbox gelegt wird. kann nicht. Ist es als Koch so? Ist es nicht eine realistische Art, Dinge zu organisieren? Es ist jedoch mühsam und nutzlos, wenn ein Koch herauskommt, der einen Vortrag hält und eine detaillierte Arrangement-Methode auferlegt. Zeit wird verschwendet. Immerhin ist es eine Technik des Organisierens. Es wird entschieden, dass es besser ist, es loszuwerden und mit dem Kochen zu beginnen, bevor es durcheinander kommt ist. (4) Was sind die Urteile und Kriterien, um sie in die Umordnungsbox zu legen? Stellen Sie die Werkzeuge, die eng mit dem Material verbunden sind, in denselben Organizer. Sie können mehrere Materialien und Werkzeuge einsetzen. Sie können weitere Organisatoren in den Organisator aufnehmen. Sie können ein Anfrageformular für eine andere Neuanordnungsbox in die Neuanordnungsbox einfügen. (5) Wie organisiere und koche ich? Der Koch wird organisieren und kochen. Der Küchenchef kocht mit den Zutaten und Werkzeugen des Veranstalters. Wenn Sie Zutaten mit leicht unterschiedlichen Attributen kochen müssen, verwenden Sie die Werkzeuge in einer anderen Organisationsbox. Es ist auch möglich, es zu verwenden. Und schließlich ist das fertige Gericht fertig. Wir werden dies in Gruppen tun, um die großartigen Gerichte zu vervollständigen. --- ☆ Bis hierher ☆ ---
(6) Zusammenfassend Das Zusammenfügen der Wörter ist objektorientiert -Identifizieren Sie die erforderlichen Datengruppen und Betriebsgruppen (Verarbeitungsgruppen) anhand von Erfahrungen, Kenntnissen, Dokumenten usw. -Organisieren, klassifizieren und strukturieren Sie Datengruppen und Operationsgruppen (Verarbeitungsgruppen). ・ Zum Organisieren, Klassifizieren und Strukturieren werden Daten (Materialien) und Operationen (Werkzeuge) verwendet, die eng mit der definierten Klasse (Organisationsbox) verbunden sind. Zuweisen und ausführen. Das war alles.
In der obigen Erklärung besteht einer der Unterschiede zu den Entwicklungsmethoden (und -programmen) bis zu diesem Punkt darin, dass eine Klasse erstellt wird. Ich möchte ein wenig über diese Klasse (Organisationsbox) erklären. Eine Klasse ist eine Grundeinheit (Organisationsbox) in einem Java-Programm, die verwandte Datengruppen (Materialien) und Operationsgruppen (Werkzeuge) enthält. Um ein Beispiel zu nennen, wenn Sie beispielsweise an eine neu angeordnete Box (Klasse) namens "Spaghetti" denken, Peperoncino, Fleischsauce, Bolonese, Pescatore, Arabita, Amatrichana, Carbonara, Alfred, Genovese, Trapanese, Napolitan, Tarako Spaghetti, Mentaiko Spaghetti, ... Sie können Materialien und Werkzeuge für Spaghetti einsetzen. Möglicherweise möchten Sie die Sortierboxen für jede Sorte wie Ölsauce, Tomatensauce, Sahnesauce und Basilikumsauce in die Spaghetti-Sortierbox legen. Wenn es sich um eine Ölsauce handelt, geben Sie Peperoncino, wenn es sich um eine Tomatensauce handelt, Fleischsauce, bolonische Zutaten und Werkzeuge nach Typ in eine Sortierbox. Und denken Sie daran, dass "Spaghetti" nicht immer im Unterricht ist. In Anbetracht der Klasse der "Lebensmittel" kann beurteilt werden, dass Spaghetti ein Material (Daten) sind. Darüber hinaus ist Peperoncino kein Material (Daten), sondern kann unter Berücksichtigung von Belägen zu einer neu angeordneten Box (Klasse) werden. Mit anderen Worten, die Organisation und Klassifizierung unterscheiden sich je nachdem, welche Art von Problem unter welchem Gesichtspunkt betrachtet wird. Natürlich kommt es auf die Person an. Unabhängig davon, welche Klasse Sie definieren, kann sie daher nicht von allen als korrekt bewertet werden und ist immer mehrdeutig. Dieser Teil ist eine relativ Quelle für Urteils- und Anerkennungsunterschiede. Je mehr Personen beteiligt sind, desto verwirrender wird er. Es ist nicht möglich zu bestimmen, welche die richtige Antwort ist. Wenn also kein Fehler vorliegt, ist es besser, mit der nächsten fortzufahren. Und Sie sollten vermeiden, erweiterbare Klassen zu erstellen, die nicht speziell erforderlich sind. Es trägt nur zur Mehrdeutigkeit bei.
Ich denke, Sie haben einen Überblick über die objektorientierten Umrisse. Als nächstes möchte ich meine Perspektive auf dieses Merkmal verlagern und mein Verständnis vertiefen. Zu den objektorientierten Merkmalen gehören die Instanziierung und die drei Prinzipien (Kapselung, Vererbung und Polymorphismus). Aufgrund dieser Eigenschaften (1) Unterstützung für die gleichzeitige Mehrfachverarbeitung durch Materialisieren / Verkörpern (Instanziieren) eines Konzepts (einer Klasse). (2) Organisieren Sie dieselben Implementierungsinhalte an einem Ort, ohne sie an mehreren Stellen zu beschreiben. (3) Verbergen Sie die reale Instanz (das Objekt) so weit wie möglich, um ihre Unabhängigkeit zu verbessern. Es wird gesagt, dass realisiert werden kann.
(** Über Instanziierung **) Warum brauchen wir also zunächst eine Instanziierung? Einfach ausgedrückt bedeutet Instanziierung, einen Kopierklon der Klasse zu erstellen und die Werte in den Mitgliedsvariablen festzulegen. Die Instanziierung erfolgt üblicherweise bei Verwendung einer Multithread-Umgebung (gleichzeitige Mehrfachverarbeitung) oder bei Vererbung / Polymorphismus. Vererbung und Polymorphismus werden später beschrieben, und zunächst wird die Instanziierung in einer Multithread-Umgebung und einer In-Thread-Umgebung nachstehend beschrieben. In einer Multithread-Umgebung kann dieselbe Verarbeitung (Daten sind unterschiedlich) zur gleichen Zeit ausgeführt werden, sodass die Klasse materialisiert / verkörpert (instanziiert) wird und für jeden Thread derselbe Objekttyp generiert und verarbeitet wird, der unterschiedliche Daten enthält. Ist üblich. Mit dieser Methode kann jeder Thread die interessierenden Daten schnell und angemessen verarbeiten. In einer Multithread-Umgebung ist jedoch nicht immer eine Instanziierung erforderlich, und es ist keine Instanziierung erforderlich, wenn die Existenz einer Klasse ausreicht. Tatsächlich erfordern Bibliotheken und dergleichen keine signifikante Teilinstanziierung unter Verwendung statischer Methoden.
Andererseits können sich mehrere instanziierte Objekte derselben Klasse gleichzeitig im selben Thread befinden. Als typisches Beispiel möchten Sie möglicherweise eine Verarbeitung unter Verwendung der Objektdaten für jedes Objekt (im Allgemeinen zeilenweise) durchführen, die basierend auf den Suchergebnissen generiert wurden. Beispiel: Berechnen Sie den Gesamtbetrag für jeden Verkaufsartikel. In diesem Fall kann natürlich die höhere Verkaufsklasse verwendet werden, solange der Gesamtbetrag berechnet wird. Mit anderen Worten, die Notwendigkeit, die entsprechenden mehreren Objekte zu erstellen, ist nicht immer wesentlich. Es gibt zwei Arten solcher Objekte, Benutzerklassen und Sammlungen (Liste, Zuordnung usw.), und Benutzerklassen sind die ursprünglichen, die die eigentliche Verarbeitungsmethode enthalten, und diejenigen, die dies nicht tun (Bean, DTO: DataTransferObject und VO). : ValueObject) Es gibt zwei Typen. Unter dem Gesichtspunkt, welcher Typ verwendet werden soll, ist es bei einer Verarbeitung, die den Status der Verkaufsdetaildaten (DB) ändert (den Wert ändert), immer noch besser, die Verarbeitung in der Verkaufsdetailklasse (Benutzerklasse) durchzuführen. Ist die richtige Perspektive. Mit anderen Worten, wenn Daten gespeichert werden sollen (keine temporären Daten) und ein Prozess zum Ändern ihres Werts vorhanden ist, ist es besser, sie mit der Benutzerklasse zu verarbeiten, die die Daten speichert (eine solche Klasse erstellen). Sollte sein). Wenn jedoch keine spezielle Verarbeitung zum Ändern des Werts vorhanden ist, können möglicherweise Klassen wie Sammlungen, Beans, DTOs und VOs verwendet werden (der Bedarf an Kapselung ist gering). Wenn das Suchergebnis als Zeichenfolgenliste zurückgegeben wird, ist es außerdem besser, die Zeichenfolgenliste (Sammlung) zu übergeben, ohne die Objektgruppe erneut einzugeben.
Aus dem oben Gesagten kann gesagt werden, dass es möglich (effektiv) ist, eine Benutzerklasse als Ganzes zu entwerfen, zu instanziieren und in mehreren gleichzeitigen Prozessen zu verarbeiten, aber es ist nicht immer wesentlich, einschließlich der In-Thread-Umgebung, und es ist flexibel. Es bedeutet, dass wir uns darum kümmern sollten. Mit anderen Worten, es ist eine Instanz der grundlegendsten Funktion in der Objektorientierung (einschließlich OOP), aber angesichts der aktuellen Situation scheint es nicht so notwendig zu sein wie das Schlagwort zu diesem Zeitpunkt. Ich denke jedoch, dass die Merkmale der Instanziierung in gewissem Maße dazu beigetragen haben, die Notwendigkeit und Gültigkeit der Objektorientierung zu überzeugen.
(** Über die drei Prinzipien **)
Als nächstes möchte ich die drei Prinzipien der Einkapselung, Vererbung und des Polymorphismus erläutern.
Zuerst werde ich jeden Begriff erklären.
Als nächstes möchte ich anhand meiner bisherigen Erfahrungen bewerten und erklären, ob diese drei Prinzipien tatsächlich nützlich sind. (1) Machen Sie das Programm unabhängiger und prägnanter, indem Sie diese drei Prinzipien anwenden. Ich denke, es ist sicher, dass Sie es schaffen können. (2) Diese drei Prinzipien sind wirksamer, insbesondere bei der Entwicklung von Grundfunktionen (Rahmen- und gemeinsame Funktionsäquivalentteile). Es scheint so als. (3) Reibungslose Entwicklung vom Fluss der objektorientierten Analyse / Entwurfsorganisation / Klassifizierung bis zur Implementierung Man kann sagen, dass es ein Mechanismus ist, der warten kann. (4) Mit einem Mechanismus wie den drei Prinzipien im erforderlichen Umfang einrichten, ohne an das Wort objektorientiert gebunden zu sein Es scheint realistisch und effektiv zu messen und umzusetzen. (5) Diese Mechanismen werden jedoch mehr als notwendig eingesetzt, um den Entwurf und die Programmstruktur zu komplizieren. Bitte beachten Sie, dass die Produktivität sinken kann. Wie oben erwähnt, sind diese drei Prinzipien nicht nur objektorientiert auf Java, sondern können auch in vielen anderen Entwicklungsumgebungen angewendet werden.
Abschließend möchte ich einen Vergleich mit dem Modul erläutern, über das manchmal gesprochen wurde. Grundsätzlich denke ich nicht, dass das, was Sie mit "Objekten" machen (verarbeiten) können, nicht mit "Funktionen" / "Modulen" gemacht werden kann. Natürlich wird angenommen, dass die Programmlänge, Speicherlänge, Verarbeitungsgeschwindigkeit usw. nicht berücksichtigt werden. Eine der Eigenschaften von "Objekten" ist, dass sie mehr als einmal gleichzeitig existieren können, andererseits können "Funktionen" und "Module" nicht mehr als eins gleichzeitig haben. Dies kann jedoch auch mit "Funktionen" und "Modulen" praktisch möglich sein, wenn eine Funktion eingebaut ist, die mehrere Prozesse realisieren kann. In Bezug auf das Schlagwort denke ich, dass der Ton "... relativ objektorientiert relativ leicht zu realisieren ist" und nicht "... realisierbar ist, weil er objektorientiert ist". Ich denke, der leicht scharfe Slogan war auch der Grund für die Verwirrung.
War nach der obigen Erklärung eine Objektorientierung wirklich notwendig? Persönlich scheint es, dass die Objektorientierung auf der Basisebene nur wenige neue Funktionen ohne Alternativen hatte, und ich denke nicht, dass dies unter diesem Gesichtspunkt wesentlich war, aber es ist effektiv und wird durch sein Erscheinungsbild erzeugt. Ich denke, man kann sagen, dass die Verbesserung von Sexualität und Qualität einen gewissen Effekt hatte. Daher scheint es, dass ein bestimmter Effekt erwartet werden kann, solange er übernommen wird, während die Vorsichtsmaßnahmen bei der Verwendung, die später beschrieben werden, beachtet werden.
Zu dieser Zeit hörte ich oft, dass die objektorientierte Entwicklung fehlschlug. Was genau bedeutete Entwicklung überhaupt mit Objektorientierung? Und was ist durch das, was wir getan haben, schief gelaufen? Ist es fehlgeschlagen, weil es die Java-Sprache übernommen hat? Die Java-Sprache steht immer noch an vorderster Front, und ich glaube, es gab nichts Tödliches. Ich vermute, dass die meisten allgemeinen Ursachen in der Systementwicklung waren. Die Fehlerursachen (in Bezug auf Kosten, Frist, Qualität) sind folgende (aus Sicht des Auftragnehmers / Entwicklers). ・ Ich habe keine angemessene Schätzung vorgenommen. Ich habe den Preis leicht gesenkt, um eine Bestellung zu erhalten. Er konzentrierte sich auf den Preis und spielte reale Perspektiven wie Erfahrung, Technologie und Struktur herunter. ・ Geringe Fähigkeit, Spezifikationen zu bestimmen. ・ Geringe Autorität, um Spezifikationen zu bestimmen. In der Entwicklung muss eine Vielzahl von Spezifikationen flexibel festgelegt werden. Die Fähigkeit und Autorität der bestellenden Partei und der Entwicklungsseite waren zu gering, um angemessene Entscheidungen und Entscheidungen zu treffen. gewonnen. ・ Geringe Kommunikationsfähigkeit Die Kommunikation zwischen der Bestellseite und der Entwicklungsseite, der Innenseite der Bestellseite und der Innenseite der Entwicklerseite ist schlecht. Auf jeden Fall hat er eine starke Einstellung, um Verantwortung zu vermeiden und Arbeit und Verantwortung an andere weiterzugeben. ・ Geringe Erfolgsbereitschaft. Die Bestellseite und die Entwicklungsseite haben ohnehin eine schwache Absicht, erfolgreich zu sein. Diese Tendenz gilt insbesondere dann, wenn viele Zeitarbeiter beschäftigt sind (weil Mitarbeiter anderer Unternehmen nicht verantwortlich sind). Stärker werden. ・ Unerfahren. Die Anzahl erfahrener Personen, die Technologie, Sprache, Middleware usw. für Entwicklungsplattformen benötigen, ist gering. Viele Mitglieder kennen keine Domänen. Ich denke, dass es die Möglichkeit gibt, dass das Wort "Fehler" erst nach dem Löschen objektorientiert verwendet werden kann. Was sind die Ursachen für objektorientierte Fehler? ・ Es wird viel Zeit für Diskussionen zur Objektorientierung aufgewendet, nicht für die ursprünglichen Spezifikationen in Analyse und Design. Es tat mir leid. · Verbringen Sie viel Zeit mit der Erstellung objektorientierter Dokumentation in Analyse und Design Ich habe gewartet. ・ Da die Klassengranularität unnötig klein und die Struktur kompliziert und tief war, dauerte die Entwicklung länger. Es war hungrig. ・ Es gab viele Mitglieder, die OOP so gut wie nie erlebt hatten. ・ Ich habe versucht, eine Entwicklungsmethode mit wenig Erfahrung zu üben. Ist es so ein Ort? Es scheint, dass so etwas nicht wesentlich war und relativ leicht vermieden werden konnte. Wie oben erwähnt, hätte die Diskussion zur Objektorientierung auf ein Minimum beschränkt und viel Zeit für die ursprüngliche Spezifikation aufgewendet werden müssen. Es sollte berücksichtigt werden, dass eine unnötig abhängige oder voreingenommene Objektorientierung nicht gut für die Kostenleistung ist.
Als nächstes möchte ich auf die Entwicklungsmethodik aus der Perspektive des Scheiterns zurückblicken. Wie heute wurden zu dieser Zeit verschiedene Entwicklungsmethoden vorgeschlagen. Diese verschiedenen Entwicklungsmethoden wurden zu einem heißen Thema und wurden als ein Thema mit Objektorientierung anerkannt, was auch zur Verwirrung über die Objektorientierung beitrug. Hauptsächlich war es ein Vorschlag, vom konventionellen Wasserfalltyp zum Kursivtyp (einschließlich des agilen Typs) zu wechseln. Es ist also nicht so, dass der Kursivschrifttyp mittlerweile zum Mainstream geworden ist, aber die Grundlagen sind immer noch der Wasserfalltyp. Es scheint, dass diese gemischte Entwicklungsmethode zur Geschichte des objektorientierten Versagens beigetragen hat. Ich denke, es war notwendig, objektorientierte und Entwicklungsmethoden grundsätzlich getrennt zu behandeln. Ich denke, viele Ingenieure und Kunden haben in dieser Zeit einen großen Beitrag zu Softwareanbietern geleistet (lacht).
Was sollen wir also mit der Dokumentation machen? Zu den objektorientierten Dokumenten gehören: Konzeptionelles Modelldiagramm, Anwendungsfalldiagramm, Anwendungsfallbeschreibung, Paketdiagramm, Analyseklassendiagramm, Analysesequenzdiagramm, Entwurfsklassendiagramm, Entwurfssequenzdiagramm, Entwurfsaktivitätsdiagramm usw. Es besteht kein Zweifel, dass es unter dem Gesichtspunkt der Kostenleistung zweifelhaft ist, ein solches Dokument auf rechtmäßige Weise zu erstellen. Es ist möglicherweise nicht möglich, in einer groß angelegten Entwicklung überhaupt zu schreiben. Obwohl sich die Leistung der jüngsten Tools zur Erstellung von UML-Diagrammen verbessert hat, ist es meiner Meinung nach schwierig, Diagramme auf großen Systemen zu zeichnen. Es wäre angebracht, eine Dokumentenerstellung anzustreben, die die erforderlichen Elemente in einer angemessenen Menge beschreibt, effektiv verwendet werden kann, leicht auf Änderungen reagieren kann, keine neuen Tools erfordert und als Ergebnis verwendet werden kann. Bei der Entwicklung grundlegender allgemeiner Funktionen (Frameworks auf App-Ebene, bei denen es sich nicht um Middleware handelt) scheint es jedoch effektiv zu sein, Klassendiagramme als temporäre Dokumente zu erstellen. Es ist sicher, dass es zeitlich und veränderlich vorteilhaft ist, objektorientierte Dokumente im Excel-Tabellenformat usw. zu organisieren, anstatt Abbildungen wie UML zu verwenden. Darüber hinaus denke ich, dass es den Vorteil hat, die notwendigen Inhalte genau anweisen zu können.
Der Startbildschirm sollte mit HTML- oder Bildschirmdesign-Tools usw. erstellt werden. Anschließend sollte ein Prototyp erstellt und bestätigt werden, ohne dass er vor dem Bereitstellungsprozess einschließlich Bildschirmübergängen bereitgestellt und im Bereitstellungsprozess verwendet wird.
Einer der Gründe für die objektorientierte Entwicklung war, dass "es ist, weil wir flexibel auf Veränderungen reagieren können" eher wie damals erklärt wurde. Die Änderungen wurden als Hotspots bezeichnet. Natürlich wird es möglich sein, diese Anforderung zu erfüllen, wenn die gesamte Implementierung bewusst von OOP implementiert wird. Wenn Sie jedoch darüber nachdenken, gibt es überall im Programm Änderungsschätzungen mit Millionen und zig Millionen von Schritten. Wenn Sie ein Kriterium einführen, das sich "höchstwahrscheinlich ändert", werden Sie auf das Thema stoßen, wie dieses Kriterium geklärt und verkörpert werden kann. Ein weiteres Problem ist, wer entscheidet, ob es hoch oder niedrig ist und wer die Kosten trägt. Es kann möglich sein, bei der Entwicklungsarbeit ein gewisses Risiko einzugehen, wenn die Aussicht besteht, dass die Betriebsarbeiten unbedingt anvertraut werden können, aber eine solche Form ist in den letzten Jahren selten geworden.
Darüber hinaus ist es nutzlos und unrealistisch, eine unvernünftige OOP durch Erraten zu erstellen, ohne zu klären, welche Art von Änderung eintreten wird. Um auf Änderungen reagieren zu können, müssen daher Schritte wie die Klärung und Bestimmung von Änderungsspezifikationen, das Design, die Programmierung und das Testen im Voraus unternommen werden. Mit anderen Worten, wir müssen einen Mechanismus aufbauen, der auf Änderungen reagieren kann. Mir ist bewusst, dass es nicht so sehr darauf ankommt, dass die objektorientierten Merkmale eine große Produktivität und Bedeutung in diesem Mechanismuskonstruktionsteil ausüben. Insgesamt unterscheidet es sich nicht wesentlich von anderen Entwicklungsmethoden und -mitteln. Schließlich ist es, wie oben erwähnt, besser, es in den erforderlichen Spezifikationen zu spezifizieren und in einer Umgebung zu realisieren, in der die Kosten und der Zeitraum aufgezeichnet werden können.
Ich habe beschrieben, was ich mir ausgedacht habe, indem ich auf die Vergangenheit zurückblickte, aber schließlich habe ich aus den Ergebnissen dieser Überlegungen die Punkte aufgelistet, die beim Üben der Objektorientierung in der Zukunft zu beachten sind. Bitte nehmen Sie Bezug darauf.
·Konzept Ein Konzept ist ein Wort, das "Eigenschaften bedeutet, die allen Dingen gemeinsam sind". Wenn es mehrere Dinge gibt, die gemeinsame Eigenschaften haben, werden sie aufgrund der gemeinsamen Punkte als der gleiche Typ angesehen. Bild gebildet von. Beispiel: Katzenkonzept (Katzenbild), Fahrzeugkonzept (Fahrzeugbild) usw. Unter einem anderen Gesichtspunkt der Klassifizierung kann von einer höheren Klassifizierung gesprochen werden. · Überschreiben Bezieht sich auf die Neudefinition einer in einer übergeordneten Klasse in einer untergeordneten Klasse definierten Methode. ·Überlast Methoden mit demselben Methodennamen, aber unterschiedlichen Argumenttypen, Nummern und Reihenfolgen in derselben Klasse Bezieht sich auf die Definition mehrerer.