Daniel hat geschrieben:1. Warum sind Klassen, Methoden und Objekte, also die Objekt-orientierte Programmierung (OOP) besser als die guten alten hassgeliebten Procedures und Functions mit ihren Abläufen?
Es ist von Vorteil, dass Objekte Daten und Funktionscode (Methoden) gekapselt von der Außenwelt in sich verwalten. Angenommen man benötigt 4 Funktionen um z.B. eine Aufgabe zu erledigen. Alle diese Funktionen werden nacheinander aufgerufen und eine ellenlange Parameterliste mit locals oder aber eine Menge Private Variablen beinhalten die Daten. Unter DOS konnte man damit Leben, denn der Programmierer wusste immer genau wie der aktuelle Stand gerade war. Angenommen unter GUI würde man so seine Eingabefenster basteln, und der Anwender macht 2 davon gleichzeitig auf ? Alle globalen Variablen (private public) können nun von außen geändert werden, was zu unvorhersehbaren Schwierigkeiten führen kann. Man kann es in den Griff bekommen (andere Sprachen müssen auch damit auskommen), aber es ist viel einfacher ein Object mit vielen Methoden und Instanzvariablen zu verwalten, als eine Menge Funktionen mit Parameterlisten ... man denke nur an die Problematik die Parameterzeile richtig zu bestücken:
Code: Alles auswählen
oWin:title := "Titel"
oWin:...
ist einfacher und sprechender als
nWin := GetWindow("Titel", .d..d... .sd..s.s sd. .sd. sad.s .s.d.)
Nun denken wir an mehrere Varianten von z.b. SLE:
Wären es Funktionen, könnte man das Verhalten nicht ändern, man müsste sein eigenes Datumseingabefeld schreiben; nicht ganz einfach mit der Messegeverwaltung von Windows. So ist es eine Klasse, von der man Ableitungen machen kann. Ich erstelle also einen neue Klasse, die alle Eigenschaften der alten erbt und ändere nur was ich anders benötige.
Wenn der Formdesigner CLASS-Code erzeugt, kann man direkt auf alle Elemente zugreifen:
oSleName:setData("Name") ... beim Function-Code, steht da ein
oXbp für alle Elemente, somit muß ich über die Clientliste das richtige SLE ermitteln,
das ist mir zu umständlich !
Noch ein Beispiel aus dem wirklichen Leben:
*** Kindererziehung
- In früher Jugend muss man alles lernen, die Anweisung lauf mal 5 Schritte vor kann ein Kind beim Laufen lernen nicht begreifen. Man unterstützt also mit der Hand und setzt Beinchen vor Beinchen -> Funktionscode, mehr geht halt noch nicht.
- 4 Jahre später sagt man hol mir bitte das Bier ... und das Kind läuft ohne über das Laufen nachzudenken und holt das Bier. -> object orientiert
- Kaum volljährig bei gleicher Bitte kommt die Antwort 'hols doch selbst, bin ich dein Diener' ... man sieht, object orientierte Programmierung muss nicht immer bessere Resultate bringen, aber es kann das Leben erleichtern
Daniel hat geschrieben:2. Wie kann man ein Objekt erklären, wie ist es charakterisiert, aufgebaut und was kann man damit machen?
Ein Objekt bezeichne ich gerne als Mischung zwischen Funktion und Daten.
Es kennt
seine Daten, gibt manche davon frei und behält andere für sich, genauso mit den Methoden. Man kann alles damit machen.
So ich hoffe es ist etwas klarer geworden. Wenn nicht ruhig weiterfragen.
Ach, ich tu's einfach ... 
