Gründe für die Entstehung von OOP

1. Firmengeschichte

Ich möchte Ihnen eine Geschichte erzählen, die zeigt, wie OOP dabei hilft, die Komplexität großer Systeme zu bewältigen. Dies ist notwendig, damit Sie den Zweck von OOP verstehen .

Es war einmal ein kleines Unternehmen, das intergalaktische Schifffahrtsdienste anbot ...

Nennen wir es Galaxy Rush. Es beschäftigte 5 Mitarbeiter. Einer arbeitete im Finanzwesen, der zweite arbeitete in einem Lager, der dritte kümmerte sich um die Lieferungen, der vierte kümmerte sich um die Werbung und der fünfte leitete das gesamte Unternehmen.

Sie waren sehr fleißige Arbeiter und haben alles geschafft. Das Unternehmen hatte einen guten Ruf und verdiente viel Geld. Doch von Jahr zu Jahr gab es immer mehr Aufträge, sodass der Chef zusätzliche Mitarbeiter einstellen musste. Mehrere weitere für das Lager, mehrere weitere für Lieferungen, noch einer für die Finanzen und ein zusätzlicher Werbeexperte, um den Marktanteil des Unternehmens auszubauen.

Und da begannen die Probleme. Es waren mehr Leute da und sie begannen sich gegenseitig in die Quere zu kommen.

Der Vermarkter belastet sein Bankkonto für eine neue Werbekampagne, sodass kein Geld für den Kauf von Produkten vorhanden ist, die dringend versendet werden müssen.

Das Lager verfügt über 10 brandneue Hyperantriebe, die einmal im Monat an einen Kunden versendet werden. Ein Kurier flog ein und nahm einem anderen Kunden ein Hyperlaufwerk ab, was dazu führte, dass sich die reguläre Bestellung von 10 Hyperlaufwerken um einen Monat verzögerte. Der erste Kurier wusste einfach nicht, dass die andere Bestellung vom zweiten Kurier ausgeführt wurde.

Der neue stellvertretende Geschäftsführer schickt einen Kurier in ein Raumschiff, um weitere Waren einzukaufen. Währenddessen warten alle anderen auf das Erscheinen eines verfügbaren Raumschiffs. Es gibt jede Menge dringende Lieferungen, aber diese Assistentin überwacht nur die Beschaffung und versucht, ihre Arbeit gut zu machen. Je besser ein Mitarbeiter seine Aufgaben erfüllt, desto stärker mischt er sich in die Arbeit anderer ein.

Bei der Analyse der Situation stellt der Chef fest, dass wichtige Ressourcen wie Raumschiff, Bargeld und Produkte nicht optimal genutzt werden. Stattdessen gilt für sie die Regel „Wer schläft, verliert“. Jeder Mitarbeiter könnte eine Ressource nehmen, die alle anderen für seine Arbeit benötigen, und dadurch die anderen Mitarbeiter und das Unternehmen insgesamt gefährden.

Es musste etwas getan werden, also beschloss der Chef, das monolithische Unternehmen in einige Abteilungen aufzuteilen. Er gründete eine Versandabteilung, eine Marketingabteilung, eine Beschaffungsabteilung, eine Finanzabteilung und eine Lagerabteilung. Niemand konnte mehr einfach das Raumschiff nehmen. Der Leiter der Versandabteilung erhielt alle Informationen über die Lieferungen und übergab das Schiff an den Kurier mit der profitabelsten Bestellung. Darüber hinaus erlaubte das Lager den Kurieren nicht, einfach die gewünschte Ware abzuholen. Stattdessen wurde die Kommissionierung der Produkte aus dem Lager zu einem kontrollierten Prozess. Die Finanzabteilung würde keine Mittel für eine Marketingkampagne freigeben, wenn sie wüsste, dass es bald zu einem Kauf kommen würde. Jede Abteilung hatte ein öffentliches Gesicht – den Abteilungsleiter.Die interne Struktur jeder Abteilung war ihre eigene Angelegenheit. Wenn ein Kurier Produkte abholen wollte, ging er zum Lagerverwalter und nicht zum Lager. Wenn eine neue Bestellung einging, wurde diese beim Leiter der Versandabteilung ( public-facing representative) und nicht bei einem Kurier ( someone not authorized to interact with the other departments) entgegengenommen.

Mit anderen Worten: Der Chef hat die Ressourcen und Aktionen, die Ressourcen betreffen, in Gruppen (Abteilungen) zusammengefasst und anderen auch verboten, in die internen Strukturen der Abteilungen einzugreifen. Abteilungsübergreifende Interaktionen mussten über eine bestimmte Person erfolgen.

Aus Sicht von OOP ist dies nichts anderes als die Aufteilung des Programms in Objekte. Ein monolithisches Programm aus Methoden und Variablen wird zu einem Programm, das aus Objekten besteht. Und die Objekte haben Variablen und Methoden.

Das Problem bestand darin, dass jeder Mitarbeiter mit jeder Ressource arbeiten und jedem anderen Mitarbeiter Befehle erteilen konnte, ohne Aufsicht oder Kontrollen. Wir haben eine kleine Einschränkung eingeführt, aber mehr Ordnung erreicht. Und wir konnten auch alles besser kontrollieren.

Das ist Teile und Herrsche in seiner reinsten Form.

2. Wie Programme erstellt werden

Ich möchte noch einen wichtigen Punkt ansprechen, der einen weiteren Vorteil von OOP verdeutlicht . Sehen Sie, dass Programme eher wie Tiere als wie Gebäude sind? Sie sind nicht gebaut. Sie sind gewachsen. Entwicklung ist ständiger Wandel. Im Baugewerbe kann man einen guten Plan haben und ihn präzise befolgen. Dies ist bei der Softwareentwicklung nicht der Fall.

Sehr oft kann man beim Programmieren etwas nicht so machen, wie man es ursprünglich beabsichtigt hatte, und muss viel nacharbeiten. Kundenanforderungen ändern sich noch häufiger.

Was aber, wenn der Kunde eine sehr genaue Spezifikation liefert? Das macht die Sache noch schlimmer. Schauen Sie sich an, was mit dem Produkt im Laufe der Zeit passiert.

Der Erfolg des Produkts wird dazu führen, dass der Kunde eine neue Version herausbringen möchte und dann noch eine und noch eine. Und natürlich müssen Sie lediglich „kleine Änderungen“ am bestehenden Produkt vornehmen. Sie sehen also, dass die Produktentwicklung eine Abfolge ständiger Veränderungen ist. Lediglich die Zeitskala ist unterschiedlich. Eine neue Version kann einmal wöchentlich, einmal monatlich oder alle sechs Monate veröffentlicht werden.

Und welche Schlussfolgerung können wir aus all dem ziehen? Die interne Struktur des Produkts muss so beibehalten werden, dass wesentliche (und kleinere) Änderungen mit minimaler Nacharbeit vorgenommen werden können.

Objektzusammenhalt

Aber das zu tun ist schwieriger als die Entscheidung, es zu tun. Wir haben bereits gesagt, dass ein Programm aus Objekten besteht, die miteinander interagieren. Zeichnen wir alle Objekte unseres Programms auf die Tafel und stellen sie durch Punkte dar. Und zeichnen wir Pfeile von jedem Objekt (Punkt) zu allen anderen Objekten (Punkten), mit denen es interagiert.

Jetzt fassen wir die Objekte (Punkte) zu Gruppen zusammen. Punkte sollten gruppiert werden, wenn die Verbindungen zwischen ihnen viel intensiver sind als die mit anderen Punkten. Wenn die meisten Pfeile von einem Punkt zu anderen Punkten in der eigenen Gruppe gehen, wurden die Gruppen korrekt gebildet. Wir sagen, dass die Punkte innerhalb einer Gruppe eine hohe Kohäsion aufweisen , während Punkte in verschiedenen Gruppen eine geringere Kohäsion aufweisen.

Prinzip der losen Kopplung

Es gibt ein „Prinzip der losen Kopplung“. Ein Programm ist in mehrere Teile unterteilt, bei denen es sich häufig um Schichten handelt. Die Logik dieser Schichten/Teile ist eng mit ihrer inneren Struktur verknüpft und sehr lose mit anderen Schichten/Teilen. Interaktionen zwischen Schichten sind normalerweise sehr reguliert. Eine Ebene verweist möglicherweise auf die zweite Ebene und verwendet nur eine kleine Teilmenge ihrer Klassen. Dies ist das Prinzip der „Aufteilung des Unternehmens in Abteilungen“, das wir zuvor gesehen haben, jedoch in größerem Maßstab.

Das Ergebnis ist, dass wir eine Abteilung nach Bedarf umorganisieren können, um ihre Effektivität zu steigern, und wir können noch mehr Leute für die Abteilung einstellen, und solange wir das Protokoll der Interaktion mit unseren anderen Abteilungen nicht ändern, werden alle vorgenommenen Änderungen dies tun bleiben lokal. Niemand muss etwas umlernen. Sie müssen nicht das gesamte System überarbeiten. Jede Abteilung kann diese Art der internen Optimierung durchführen, wenn die Mechanismen für die abteilungsübergreifende Interaktion gut gewählt sind.

Gut gewählt. Was aber, wenn sie nicht gut ausgewählt sind? Dann sind die Veränderungsmöglichkeiten schnell erschöpft und man muss das gesamte System neu gestalten. Dies muss von Zeit zu Zeit erfolgen. Sie können die Zukunft nicht vorhersagen, aber Sie können die Anzahl der Wiederholungen auf ein Minimum beschränken.

Prinzip der Abstraktion

Die Art und Weise, wie Abteilungen strukturiert sind und wie sie interagieren, ist das „ Abstraktionsprinzip “. In der Programmierung wird es verwendet, um zu bestimmen, wie ein Programm am besten in seine Bestandteile zerlegt werden kann und wie diese Teile interagieren sollen. Wir können das Prinzip erneut anwenden und die resultierenden Teile in Teile aufteilen, bis wir das Programm in einzelne Klassen zerlegt haben.

Die interne Struktur dieser Teile zu verbergen und die Interaktionen mit anderen Teilen strikt einzuschränken, ist Kapselung . Kapselung und Abstraktion sind Eckpfeiler von OOP . Ein gutes Programm muss diesen beiden Prinzipien folgen. In Zukunft werden wir uns die restlichen Prinzipien ansehen und untersuchen, welche Vorteile sie bieten.