• Tutorials
• Downloads
• Referenz
• NoPaste
• FAQ

Tutorial

Warum OOP?

von ytwinky

Seite 5 von 5

Z.B. könnten wir eine Map zeichnen wollen, aber was wäre, wenn wir vergäßen, diese auch zu laden? Der Zeiger auf den Puffer mit den Map-Daten ist ungültig und beim Versuch, die Map zu zeichnen, wird das Programm höchstwahrscheinlich abstürzen. Doch mit einem CONSTRUCTOR, der ohne Wenn und Aber automatisch aufgerufen wird, könnte dieser ein spezielles Flag setzen, das meldet, die Map sei noch nicht geladen und deshalb das Objekt nicht benutzt werden sollte. Wir können auch einen Pointer zuweisen(ALLOCATE), damit, wenn die MAP-Laderoutine eine Neuzuweisung(REALLOCATE) benötigt, es auch etwas zum (Neu-)Zuweisen gibt(und selbstverständlich wird der DESTRUCTOR den auch wieder entfernen(DEALLOCATE) am Ende):

Würden wir jetzt Draw() ohne CONSTRUCTOR aufrufen, würde Map() den Puffer bei Map_Daten nehmen, um Tiles zu zeichnen. Da jedoch die Map noch nicht geladen wurde, ist der Puffer leer! Das könnte sehr gut einen Absturz bewirken! Wenn aber ein CONSTRUCTOR benutzt wird, richtet dieser alles vorher ein und es können keine Fehler auftreten.
In der Praxis wären wir aber zu vorsichtig, um Draw() aufzurufen, ehe Load() fertig ist. Aber falls wir das vergessen oder einen Fehler machen sollten, erspart uns diese Art der Programmentwicklung einen Haufen Ärger.
Eine andere Sache, die uns OOP ermöglicht, sind Properties(Eigenschaften). Wie ich schon erwähnte, möchten wir alle Variablen innerhalb eines Objektes vor Zugriffen schützen, damit keiner sie ändern kann, denn sonst bekämen wir Probleme. Aber immer eine SUB zu benutzen, um auf Variablen zuzugreifen, wäre etwas unbequem. Deshalb verwenden wir PROPERTIES. Sie sind fast so etwas wie Variablen und sie verhalten sich fast wie Variablen - z.B. wenn x eine Property von meinUDT ist, könnten wir Folgendes tun:

aber in Wirklichkeit sind PROPERTIES eine besondere Art von Prozeduren, d.h. wenn wir versuchen, eine Variable zu ändern, machen wir das nicht direkt, sondern wir beauftragen das Objekt damit, sie zu ändern. So könnte z.B. wenn wir eine Property Map.x hätten, die Map sich automatisch neuzeichnen, wenn Map.x geändert würde. Das würde aber nicht geschehen, wenn wir die Variable direkt änderten, da nun eine PROPERTY eine SUB in Verkleidung ist, können wir das tun. Auf diese Weise vermeiden wir die SCOPE-Probleme und müssen nicht die ziemlich umständliche SUB benutzen, nur um Sachen zu ändern.

Klar ist, wie wir es letztendlich machen, bleibt uns selbst überlassen. Es könnte anfangs einfacher sein, ohne Properties, OPERATORen oder aber auch CONSTRUCTORen und DESTRUCTORen auszukommen. Diese Sachen sind spezielle Extras, die mit dem OOP-Paradigma kommen. Wir könnten zum Anfang nur Methoden benutzen und alle Variablen PRIVATE machen, das ist immer noch viel sicherer und cleverer, als UDTs zu benutzen, bei denen alles PUBLIC ist(also frei zugänglich).
So bekämen wir aber einen Eindruck von OOP und vielleicht lernen wir, es zu genießen und ziehen es der bloßen prozeduralen Programmierung vor.
OOP ist beileibe nicht die Universallösung für alle Fälle. Ich benutze OOP nicht überall und mit aller Gewalt, aber ich benutze sie, woimmer es geht, denn es kann mir eine Menge Ärger ersparen und hilft mir, Sachen richtig zu machen. Und nebenbei gesagt: OOP und prozedurale Programmierung lassen sich nebeneinander verwenden. Wie ich schon sagte, benutze ich OOP nicht für Alles - für einige Sachen reichen eine klassische Function oder Sub vollkommen aus. Aber wenn es möglich ist, wenn es sinnvoll ist, wenn es Sachen leichter, sicherer und klarer macht, dann nehme ich OOP.
[/Übersetzung]
So, wann ich dazu komme, diese Übersetzung noch mal zu überarbeiten, weiß ich noch nicht..
Bis bald
ytwinky

Gehe zu Seite  1  2  3  4  5  

Zusätzliche Informationen und Funktionen
Das Tutorial wurde am 31.01.2008 von ytwinky angelegt. Die aktuellste Version wurde am 13.08.2010 von ytwinky gespeichert.	Bearbeiten     Versionen