Buchempfehlung
Windows-Programmierung. Das Entwicklerhandbuch zur WIN32-API
Windows-Programmierung. Das Entwicklerhandbuch zur WIN32-API
"Der" Petzold, das über 1000 Seiten starke Standardwerk zum Win32-API - besonders nützlich u. a. bei der GUI-Programmierung in FreeBASIC! [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 4 von 5

Wenn wir also einen UDT haben und eine Anzahl von Prozeduren, die genau mit diesem UDT arbeiten, wird es irgendwie logisch, dass diese SUBs auch zu einem Teil des UDTs werden und nicht zu abgetrennten Einheiten. So wird ein Teil des wirklichen Lebens simuliert; z.B. in einer Unternehmensstruktur verteilt ein Vorgesetzter Aufgaben an seine Mitarbeiter zur Erledigung. Der Chef macht keine Finanzbuchhaltung mit Unterstützung seiner Mitarbeiter, sondern er weist diese an, es zu tun! So erscheint es verständlicher, einem Sprite die Anweisung zu geben, sich selbst zu zeichnen, als eine Prozedur anzuweisen, ein Sprite zu zeichnen und einen UDT zu benutzen, der dieses enthält. Oder z.B. Map-Objekte:

Type MapType
  As Integer x, y
  As Any Ptr tiles
End Type

Declare Sub LoadMap (DateiName As String, Map As MapType)
Declare Sub DrawMap (Map As MapType)
Declare Sub MoveMap (Map As MapType, x As Integer, y As Integer)

Was fällt bei all diesen SUBs auf?
Sie haben alle einen Parameter, bezeichnet mit "Map As MapType"! Dieser entfällt aber bei Benutzung von OOP. Es lassen sich einfach die SUBs "Map.Load, Map.Move und Map.Draw" verwenden, anstelle von "LoadMap, DrawMap und MoveMap". Es braucht auch kein Map-Parameter an sie übergeben zu werden; sie sind ein Teil des Map-Objekts und haben deshalb einen versteckten Parameter, der ihnen übergeben wird.
Hoffentlich entsteht jetzt eine Idee, warum OOP einen Sinn ergibt. Es ist wirklich eine ganze andere Abstraktion, die einige Ideen auf die nächsthöhere Ebene überträgt. UDTs gibt es nicht im wirklichen Leben; auch Prozeduren spielen keine wirkliche Rolle. Auf dem unteren Level sind die Variaben getrennt, die Prozeduren in den UDTs sind überhaupt nicht 'Teil' von irgendetwas und alle Prozeduren sind wirklich einfach nur GOTO-Anweisungen(naja, es ist schon etwas besser, doch ich werde jetzt nicht auf Einzelheiten eingehen). Aber OOP bewahrt uns vor SCOPE-Problemen, läßt uns leichter arbeiten und läßt den Quellcode eleganter aussehen und auch 'logischer'!
Aber OOP geht noch weiter als QuellCode eleganter und 'logischer' erscheinen zu lasssen. Es macht viele Dinge einfacher und ermöglicht es uns, interessante Dinge zu machen, die sonst nicht möglich wären. Z.B. Strings: Normalerweise wird das '+' benutz, um zwei Zahlen zu addieren, aber was ist, wenn wir damit zwei Strings verketten wollen? Dafür ist das Operator-Überladen da! Wenn wir also ein String-Objekt haben, können wir den '+'Operator für das Objekt benutzen und er macht etwas völlig anderes! Das gilt aber auch für viele andere der Standard-Operatoren.
Und dann gibt es RAII.
cha0s hat auch ein Tutorial über RAII, aber einige Leute könnten das nicht so gut verstehen. Was es grundsätzlich bedeutet ist, dass wenn ein Objekt erzeugt wird, dieses Objekt dann selbst kontrolliert, welche Ressourcen es benötigt. Nehmen wir mal einen Puffer im Speicher. Wenn wir einen Puffer erstellen(meinetwegen zum Speichern von Map-Daten), benötigen wir einen Pointer und wir brauchen Allocate/ReAllocate/DeAllocate. Was passiert, wenn wir DeAllocate vergessen? Wir kriegen eventuell Speicherlöcher und Probleme! Doch wenn wir das in ein Objekt hineinpacken, wird das Objekt automatisch den Speicher anfordern(ALLOCATE), wenn es welchen benötigt und sobald das Objekt beendet wird(das ist am Programmende oder am Ende der Prozedur, in der es erstellt wurde - abhängig vom SCOPE), gibt es automatisch den Speicher wieder frei und es gibt keine Speicherlöcher(oder verschwendeten Speicher) durch Vergessen des Freigebens von Speicher(DeAllocate), wenn wir mit der Prozedur fertig sind.
Das geschieht mit CONSTRUCTORen und DESTRUCTORen, die zwei spezielle Arten von Prozeduren sind, weil sie automatisch ausgeführt werden, wenn ein Objekt erzeugt oder beendet wird. Eine andere nette Eigenschaft ist, dass sie uns das Objekt einrichten lassen und dass es gültig ist, bevor irgendeine Methode aufgerufen wird.

 

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