object oriented?

[wieschoo]

Ich glaube langsam versteh ich, was du meinst. Du denkst, dass für alle deine Aufgaben man eine andere Klasse implentieren sollte.

Klasse 1:Beginn, Daten einlesen
Klasse 2:Bearbeitung, Daten ändern
Klasse 3:Bearbeiten, vergleichen vorher nachher
Klasse 4:Ende, Daten speichern

Wenn du aber deine Daten in ein Array, das z.B. privat ist, innerhalb einer Klasse speicherst, dann hat dein Array class scope und ist in diener gesamten Klasse sichtbar. Du solltest für alle Aufgaben Methoden(Funktionen) schreiben:

Methode 1:Beginn, Daten einlesen
Methode 2:Bearbeitung, Daten ändern
Methode 3:Bearbeiten, vergleichen vorher nachher
Methode 4:Ende, Daten speichern

Um festzustellen, ob Daten geändert worden kannst du private Variablen

bool flag_change =false;

in der Funktion datenändern(); wird dann

flag_change =true;

ausgeführt.
Diese Klasse würde nur dann einen Sinn machen, wenn sie alle Aufgaben(einlesen, verarbeiten, speichern) übernimmt, da es hier um nur ein Objekt geht.
Die Klasse verwaltet alles intern (auch das Array). Somit muss die Klasse dafür sorgen, dass auch alles gesichert wurde, sodass nach dem Auflösen eines Objektes auch alle Daten in einer textfile gesichert wurden.

Wenn du möchtest, kann ich die für das Beispiel Memberlist dir zeigen, dass auch alles in C/C++ funktioniert.

 

[Thomasio]

Vielleicht habe ich einfach nur das falsche Beispiel, ich versuche halt immer mir selbst eine praktische Aufgabe zu stellen, wenn ich irgendwo was gelernt habe, um zu überprüfen, ob ich es denn verstanden habe, weil copy & paste aus nem Beispiel herzlich wenig darüber aussagt ob ich es überhaupt kann
Nachdem ich nun mal von Webseitenprogrammierung in php her komme suche ich mir da meistens etwas, was ich mal in php gemacht habe und übersetze es mir dann in C++, was logischerweise nicht immer ganz toll Sinn macht, vor allem weil meine php scripts alle von der Netzwerkverbindung und der mysql Datenbank leben, während meine ersten Gehversuche in C++ mini Anwendungen ohne echten Sinn und ganz ohne Netzwerkfunktion sind

Wenn ich also eins meiner scripts aus meiner HP nehme, wie z.B. die Mitgliedsverwaltung, dann ist der allererste grundlegende Unterschied mal, dass ein php script nicht permanent läuft, sondern immer wieder neu aufgerufen wird, bei jedem Aufruf seine Daten aus der Datenbank klaubt und Änderungen wieder zurück schreibt bevor es beendet wird, während eine C++ Anwendung irgendwie in einem endless loop immer wieder auf Eingabe wartet

Logischerweise stelle ich mir vor, dass eine C++ Anwendung eben NICHT bei jedem Schleifendurchlauf sämtlich benötigten Daten neu laden muss, es reicht völlig, wenn bei Programmstart alles EINMAL geladen wird und im Speicher bleibt solange das Programm läuft, Änderungen nur im Speicher durchgeführt werden und erst bei Programmende sämtliche Änderungen auf einmal gespeichert werden, was z.B. auch undo Funktionen oder Programmende ohne speichern ermöglicht

Was mir beim allersten Schritt in Richtung OOP aufstösst ist halt, wenn sämtlich Variablen immer unsichtbar sind, dann kann ich sie halt nirgendwo verwenden, ich muss im php Stil in jeder Klasse immer sämtliche Daten neu laden, der einzige Weg Daten zwischen 2 Klassen auszutauschen ist es sie in einer Datei zu speichern und diese Datei immer wieder neu lesen und schreiben, was im Prinzip das Gleiche ist, wie eine globale Variable, nur dass die Variable in diesem Fall eine Datei mit wechselndem Inhalt ist, genausogut könnte ich bei Programmstart einen ewig grossen globalen string definieren, aber das kanns ja wohl nicht sein, oder?
1000de von Schreib/Lesezugriffen auf die Festplatte, auf Daten die schon 100 mal geladen wurden, alles nur weil am Ende einer Klasse sämtliche nicht globalen Variablen einfach gelöscht werden?
1000fache CPU Belastung, nur um 100fach die gleiche Berechnung neu zu machen, nur weil das Ergebnis der letzten Berechnung nicht mehr existiert, bzw in einer Datei gespeichert wurde die ich 100fach neu einlesen muss?

Wenn DAS wirklich der Sinn der Sache wäre, dann würde OOP in C++ einen gewaltigen Rückschritt in Richtung php Stil bedeuten, wo jeder neue Durchlauf des endless loop quasi einem neuen Programmaufruf gleichkommt, und auch wenn ich in diesem Fall verstehen würde, wie das Ganze funktioniert, auch wenn es im code nett und übersichtlich aussieht alles sauber nach Klassen eingeteilt zu haben, für dem PC bedeutet es 1000fache Mehrarbeit
Kann es wirklich der Sinn von OOP sein einen Rechner 90% der Zeit mit Wiederholung bereits erledigter Aufgaben zu beschäftigen, nur damit der Programmierer bessere Übersicht im code hat?

 

[wieschoo]

ich muss im php Stil in jeder Klasse immer sämtliche Daten neu laden, der einzige Weg Daten zwischen 2 Klassen auszutauschen ist es sie in einer Datei zu speichern und diese Datei immer wieder neu lesen und schreiben,

Eben nicht! Jede richtig implentierte Klasse stellt eine get-Methode zur Verfügung. Somit braucht man nicht:

variableglobal = class.var;

schreiben, sondern man schreibt:

class2.setwert(class1.getwert1());

Was jedoch kein guter Programmierstil ist. Wenn 2 Klassen mit einer Variable arbeiten, sollte man sich überlegen, ob es einen Sinn macht nicht gleich alles in eine Klasse zu implentieren.

Außerdem können Variablen auch public sein. Man deklariert sie nur als privat, wenn man etwas überprüfen möchte:

set(int parameter)
{
 if (parameter > 0 && parameter < 100)
{ myvariable = parameter;}
else
{ return false;}

Kann es wirklich der Sinn von OOP sein einen Rechner 90% der Zeit mit Wiederholung bereits erledigter Aufgaben zu beschäftigen, nur damit der Programmierer bessere Übersicht im code hat?

Nein. Je nachdem wie gut man seinen Code organisiert, desto weniger wird der "CPU ausgelastet". Deshalb gibt es ja auch UML, CRC-Karten, Booch-methode, OMT.

OOP ist einfach nur ein anderes Denken, wir denken in Objekten, Bleistifte und nicht in einzelnen Variablen bleistiftfarbe. Alles was zum Bleistift gehört(spitzen(),schreiben(),bool spitz, int farbe, int härte) kommt in eine Klasse.

 

[Thomasio]

Ich glaube ich gebs derweil mal auf mit OOP, das ist eindeutig zu hoch für mich, ich kapiere wirklich nicht mal die allerersten Grundgedanken dahinter

Ich sehe einfach nicht, wie überhaupt irgendein Programmteil funktionieren soll, ohne Zugriff auf zumindest teilweise Variablen von anderen Programmteilen

Wenn ich einen Ball zeichnen will, dann kann ich das in einem Beispieltutorial wunderbar mit einer Klasse machen, solange ich die genauen Koordinaten einfach vorgebe, ich kann das sogar mehrmals machen, muss aber jedesmal wieder die Koordinaten vorgeben

Wenn ich das in einem Spiel machen will, wo der Ball abhängig von irgendwelchen Spielfiguren gezeichnet wird, wo ich vor zeichnen erstmal feststellen muss, ob der Ball im Bild bereits existiert und wenn ja, dann muss der alte Ball gelöscht werden bevor der neue Ball gezeichnet wird, dann weiss meine Klasse weder woher die Koordinaten für den Ball kommen sollen, weil die Klasse Ball keinen Zugriff auf Variablen der Klasse Spielfigur hat, noch ob der Ball überhaupt im Bild existiert, das Objekt wird in der Klasse gezeichnet und sofort wieder gelöscht, es existiert nur noch auf dem Bildschirm und ich müsste für jede noch so kleine Änderung im Bild den gesamten Bildschirm neu berechnen und komplett neu zeichnen, schlimmer, ich müsste auch ohne Änderungen im Bild ständig das Bild neu berechnen und neu zeichnen, einfach auf Verdacht, dass sich ja irgendwas geändert haben könnte, weil meine Klasse Bildschirmausgabe nun mal nicht weiss, wenn sich in irgendeiner anderen Klasse irgendein unsichtbarer Variablenwert ändert

Kann es sein, dass ich mich einfach nur selten dämlich anstelle? Ist mir ja schon peinlich, nach 1 Woche studieren nicht mal die Grundgedanken zu verstehen

 

[jsendrow]

vielleicht ist es wirklich zu früh für Dich um mit OOP anzufangen. Wenn Du folgenden Satz verstehst, dann wirst Du soweit sein:

"Dein grundlegender Fehler liegt darin, zu versuchen prozedurales Programmieren mit Klassen zu implementieren."

Sicher, du "benutzt" Klassen, aber solange Dein Denken prozedural ist, macht das einfach keinen Sinn. OOP programmieren heißt nicht, Klassen zu benutzen. Es heißt, seine Denkweise umzustellen auf eine andere Sicht der Dinge. Klassen sind nur ein (ideales) mittel zum Zwecke diese Sicht dann in Programmcode umzusetzen . Man _kann_ sogar in reinem C Objektorientiert arbeiten (was zugegeben sehr aufwendig ist). Nicht von ungefähr hiess die erste Version von C++ tatsächlich "C with Classes".

Es ist grundlegend falsch zu versuchen, ein prozedurales Skript in c++ "zu übersetzen". Das kann so nicht funktionieren, weil die Vorgehensweise eine komplett andere ist. Und solange Du nur mit kleinen Skripten arbeitest (klein im Sinne von weniger als 10k Zeilen SOurcecode) wirst Du Dir auch schwer tuen den Sinn von OOP zu erkennen. Aber jetzt versuch Dir mal vorzustellen, Du müßtest ein Projekt mit, sagen wir, 100k Zeilen Sourcecode in php schreiben. Was schätzt Du bei wieviel Zeilen Du den Überblick verlieren wirst? Gerade Deine heißgeliebten globalen Variablen sind der Tod für jedes größere Projekt, weil Du aus jeder beliebigen Zeile des Sourcecodes heraus auf Sie zugreifen kannst. Jede noch so kleine Änderung an eine Stelle deines Projektes kann so beliebige Auswirkungen auf beliebige andere Stellen des Projektes haben. Du änderst an einer Stelle den Inhalt einer Variablen, und eine ganz andere Stelle, an die Du nicht gedacht hast, die ebenfalls diese variable benutzt erzeugt dann plötzlich einen Fehler.

Genau das ist das Problem mit prozeduralen Sprachen. Ab einer bestimmten Projektgröße verlieren selbst die besten Programmierer einfach den Überblick.Vor diesem Hintergrund ist OOP ursprünglich entstanden. Es ging darum einen Weg zu finden, Sourcecode anders zu organisieren um auch bei großen Projekten den Überblick zu bewahren.

Klassen kapseln Funktionalität und Information und stellen diese nach Außen hin nur über Schnittstellen zur Verfügung. Nur eine Klasse selbst kann ihre eigenen daten bearbeiten. Andere Klassen können/dürfen das nicht, bzw der Programmierer selbst hat die Kontrolle darüber, welche Teile seiner Klasse nach aussen sichtbar sind undw elche nciht (public/private) INdem Du getter/setter methoden benutzt anstatt direkt auf variablen zuzugreifen kannst Du sicherstellen, daß die Werte der Variablen immer in den vorgegebenen Bereichen liegen usw usw.

Sicher, OOP ist mehr als nur eine andere Art, den Sourcecode zu organisieren, doch erstmal sollte das für einen denkanstoss reichen.

 

[CSANecromancer]

Ich glaube ich gebs derweil mal auf mit OOP, das ist eindeutig zu hoch für mich, ich kapiere wirklich nicht mal die allerersten Grundgedanken dahinter.

Hi, hi, du erinnerst mich sehr an mich selbst. Ich hatte auch wahnsinnige Probleme, bis ich dann mal über ein Text Adventure-Spielchen (M.U.D.) gestolpert bin, was so genial organisiert war, daß man das Prinzip der OOP von selber mitbekommen hat. Aber ich denke, ich kann dein grundlegendes Problem noch gut nachvollziehen.

Ich sehe einfach nicht, wie überhaupt irgendein Programmteil funktionieren soll, ohne Zugriff auf zumindest teilweise Variablen von anderen Programmteilen.

Exakt. Damit beschreibst du ganz klar und präzise dein echtes Problem. Du siehst einfach nicht den Sinn und überhaupt die Einsatzmöglichkeit der OOP. Das hat nichts mit doof oder zu dämlich zu tun. Wenn man jahrelang prozedular programmiert hat, dann ist OOP ein ziemlicher Tritt in's Gekröse. OOP ist nicht nur eine Syntaxform. OOP ist nicht nur eine Kapselung von Daten mit Methoden. OOP erfordert im Design eine völlig andere Vorgehensweise als prozedurale Programmierung.

Wenn ich einen Ball zeichnen will,

Und schon quietschen bei mir die Bremsen das erste Mal.
Einen Ball zeichnen, ok.
Früher hätte ich dazu einfach eine Funktion in die Tasten gehämmert, die mir diesen Ball brutal und ohne Rücksicht auf Verluste auf den Bildschirm / Canvas zeichnet.
OOP erfordert aber erstmal tiiieef einatmen, entspannen, nachdenken.
Einen Ball zeichnen. Das sind schon mal 2 Dinge:
1. Objekt Ball.
2. Methode zeichnen.
Aber stimmt das so? Nein. Denn es stellt sich die Frage: WO soll der Ball gezeichnet werden? Auf dem Bildschirm? Einem Drucker? Einem Speicherbereich (Stichwort Blitting)?
Also gibt es noch ein weiteres Objekt X innerhalb dessen der Ball gezeichnet werden soll. Der Einfachheit halber gehe ich einmal vom Bildschirm aus. Das ergibt:
1. Objekt Bildschirm.
2. Objekt Ball.
3. Methode Ball zeichnen.
Und wieder komme ich in's Grübeln. Methode Ball zeichnen. Wohin gehört die denn? Zum Bildschirm? Oder zum Ball?
Und hier gibt es zwei Möglichkeiten:
- Entweder man teilt dem Objekt Ball mit, wo ein Objekt Bildschirm ist, verknüpft den Bildschirm mit dem Ball und führt dann die Methode Zeichnen innerhalb des Objekts Ball aus. Ehrlich gesagt - nicht so mein Fall.
- Oder man teilt dem Objekt Bildschirm mit, daß es ein Objekt Ball gibt und das Objekt Bildschirm bekommt die Methode zeichnen. Das wäre eher so mein Ansatz.

Wenn ich einen Ball zeichnen will, dann kann ich das in einem Beispieltutorial wunderbar mit einer Klasse machen, solange ich die genauen Koordinaten einfach vorgebe, ich kann das sogar mehrmals machen, muss aber jedesmal wieder die Koordinaten vorgeben

Wenn ich das in einem Spiel machen will, wo der Ball abhängig von irgendwelchen Spielfiguren gezeichnet wird,

Und wieder heisst es Einbremsen.
Da sind schon wieder neue Objekte, nämlich Spielfiguren. Das würde ich nicht so einfach ignorieren. Ok, in altem Spagetthicode kann ich die Spielfiguren erstmal ignorieren, aber vom Design her solltes du die bei der OOP nicht so nonchalant übergehen.

wo ich vor zeichnen erstmal feststellen muss, ob der Ball im Bild bereits existiert und wenn ja, dann muss der alte Ball gelöscht werden bevor der neue Ball gezeichnet wird, dann weiss meine Klasse

Welche Klasse denn?
Bei mir sähe es derzeit so aus, daß ich ein Objekt Bildschirm habe und dieses kann als Membervariablen ein Objekt Ball und ein oder mehrere Objekte Spielfiguren haben. Die ganz grobe Frage also, ob der Ball denn existiert, kann mir dann mein Objekt Bildschirm aber ganz sauber beantworten.

weder woher die Koordinaten für den Ball kommen sollen, weil die Klasse Ball keinen Zugriff auf Variablen der Klasse Spielfigur hat, noch ob der Ball überhaupt im Bild existiert, das Objekt wird in der Klasse gezeichnet und sofort wieder gelöscht, es existiert nur noch auf dem Bildschirm und ich müsste für jede noch so kleine Änderung im Bild den gesamten Bildschirm neu berechnen und komplett neu zeichnen, schlimmer, ich müsste auch ohne Änderungen im Bild ständig das Bild neu berechnen und neu zeichnen, einfach auf Verdacht, dass sich ja irgendwas geändert haben könnte, weil meine Klasse Bildschirmausgabe nun mal nicht weiss, wenn sich in irgendeiner anderen Klasse irgendein unsichtbarer Variablenwert ändert

Und exakt das wäre der Grund, weswegen ich mir ein Bildschirmobjekt machen würde, was die anzuzeigenden Spielelemente beinhaltet (ganz grob gesagt). Der Bildschirm kann dann ganz wunderbar steuern:
Bildschirm->Ball->MoveTo(X, Y): Den Ball bewegen
Bildschirm->CheckDistance(Ball, Spielfigur): Abstand zwischen Ball und Spielfigur berechnen
Bildschirm->Refresh: Das tatsächliche Bild auf dem Monitor neu zeichnen
etc. pp.

Um mal beim Bildschirm->Ball->MoveTo(X, Y) zu bleiben:
Innerhalb des Objekts Bildschirm will ich erstmal nur den Ball bewegen. Wie das programmiertechnisch exakt umgesetzt wird, haue ich zur Not in das Ball-Objekt. Sollte sich der Ball jetzt nicht richtig bewegen, dann weiss ich, daß im Objekt Ball etwas nicht stimmt und kann mir das vornehmen. Stottert dagegen eine Spielfigur herum, schaue ich mir das Objekt Spielfigur nochmal an. Aber ich muß nicht ein paar Tausend Zeilen Source im Objekt Bildschirm abrackern.
Lass mal eines der Objekte in einem alten prozeduralen Programm falsch zappeln. Dann fängst du bei main() an und darfst mit dem Debugger Schritt für Schritt durchlaufen und schauen, daß sich auch ja nirgends irgendeine globale Variable unbeabsichtigt ändert. Und nach jeder Variablenänderung musst du überlegen, ob du damit das Verhalten irgendeines anderen "Dings" im Programm beeinflusst. Solche Programme habe ich auch schon geschrieben und das Debuggen war schon eine Qual, eine Wartung oftmals schlechterdings unmöglich.

Kann es sein, dass ich mich einfach nur selten dämlich anstelle? Ist mir ja schon peinlich, nach 1 Woche studieren nicht mal die Grundgedanken zu verstehen

Nein, das kommt dir nur so vor und braucht dir, meiner Meinung nach, keineswegs peinlich zu sein.
OOP ist eine andere Denkweise, um an ein Programmproblem heranzugehen, nicht nur eine Syntaxfrage. So doof es vielleicht klingen mag, aber vielleicht erhälst du einen besseren Einstieg in OOP, wenn du dir das Denkprinzip mehrmals durchgrübelst. Und nur nicht aufgeben, das hat bei mir auch recht lange gedauert.

Wenn du willst, dann können wir uns ja eine Kommunikationsplattform suchen (Mail, ICQ, wasweissich), du überlegst dir ein Miniprojekt zum Üben und ich helfe dir, die "OOP-Sichtweise" für das Projekt zu bekommen.