Buchempfehlung
MySQL kurz & gut
MySQL kurz & gut
Das preiswerte Taschen- buch stellt MySQL-rele- vante Inhalte systematisch und knapp dar, sodass es sich optimal zum Nach- schlagen beim Pro- grammieren eignet. [Mehr Infos...]
FreeBASIC-Chat
Es sind Benutzer im FreeBASIC-Chat online.
(Stand:  )
FreeBASIC bei Twitter
Twitter FreeBASIC-Nachrichten jetzt auch über Twitter erhalten. Follow us!

Tutorial

Warum OOP?

von RedakteurytwinkySeite 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):

Type mapType
  Public:
    Declare Constructor ()
    Declare Destructor ()

    Declare Sub Load (DateiName As String)
    Declare Sub Draw ()
    Declare Sub Move (neu_x As Integer, neu_y As Integer)
  Private:
    As Ubyte Ptr _Map_Daten
    As Uinteger _Map_Breite, Map_Hoehe
    As Integer _x, _y
End Type

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:

meinUDT.x = 3
Print meinUDT.x

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 Gehe zu Seite  1  2  3  4  5  
Zusätzliche Informationen und Funktionen
  • Das Tutorial wurde am 31.01.2008 von Redakteurytwinky angelegt.
  • Die aktuellste Version wurde am 13.08.2010 von Redakteurytwinky gespeichert.
  Bearbeiten Bearbeiten  

  Versionen Versionen