OOP: soll man jetzt alles in ne Klasse packen oder watt?

Ist das ernst gemeint? Irgendwie wirkt das alles sehr unlogisch auf mich.

volkard

der fred schrieb:

Ist das ernst gemeint? Irgendwie wirkt das alles sehr unlogisch auf mich.

ist auch unfug.
pack nur die sachen in klassen, die sich nicht wehren.

Hm. Ich les gerade "Java ist auch eine Insel" und da kommt das so rüber?

byto

Offenbar hast Du noch nicht sehr weit gelesen.

volkard

der fred schrieb:

Hm. Ich les gerade "Java ist auch eine Insel" und da kommt das so rüber?

java.
wenn ich nur nen hammer als werkzeug hätte, würde ich die schrauben auch in die wand kloppen müssen.

Also ich bin ja grade noch im Lernen. Meinst du, ich sollte auf C++ umsatteln?

volkard

der fred schrieb:

Also ich bin ja grade noch im Lernen. Meinst du, ich sollte auf C++ umsatteln?

früher oder später solltest du c++ und java gelernt haben. mit was du anfangen solltest, kann ich dir nicht sagen, da ich dich nicht kenne.

DocJunioR

Aaallsoooo...
ein klares Jaein!

In Java musst du alles in Klassen verpacken, aaaaaaaber ein Programm in eine einzelne Klasse zu pappen ist selten sinnvoll.
Klassen sind Funktionsgruppen.
Beispielsweise sämtliche Sachen, die mit Textdateien in einem Textprogramm zu tun haben könnten in eine Klasse (also laden, speichern, löschen, ...)

Wichtig ist die Kapselung. Alles in eine Klasse hauen- dann kannst auch Basic programmieren..

DEvent

Klar macht man aus allem eine Klasse.

Nenn mir mal ein Beispiel wo es sich absolut nicht auszahlt es in eine Klasse zu packen.

Beispiel Texteditor:
- Hauptfenster mit der main()

- Menüs (erstellt alle Menüs)
- MenuDatei (erstellt nur das Menu Datei)
- MenuBearbeiten (erstellt nur das Menu Bearbeiten)
- MenuHilfe (erstellt nur das Menu Hilfe)

- Die ganzen Listerns für die Menüs (wie BeendenListener, NeuListener, SpeichernListener, ...)

- Textfenster (zeigt und bearbeitet den Text, als Kind-Fenster im Hauptfenster)

- Singelton Config (speichert und läd die Konfiguration des Programmes)

- die ganzen Dialoge als Klassen

Das war so ganz grob. Der ganze Code schön in Klassen verpackt.
Btw, ein namespace oder package ist ja auch eine Art Klasse, dessen Member alle static sind und man von der Klasse keine Objekte erzeugen kann.

Ist halt OOP. Wems nicht gefällt, kann ja LISP oder PROLOG nehmen :p

volkard

DEvent schrieb:

Klar macht man aus allem eine Klasse.
Nenn mir mal ein Beispiel wo es sich absolut nicht auszahlt es in eine Klasse zu packen.

double sqr(double x){
   return x*x;
}

wenn man das is eine klasse packen sollte, dann in double rein. das geht aber nacht. dann lieber ohne klasse.

Bashar

DEvent schrieb:

Ist halt OOP. Wems nicht gefällt, kann ja LISP oder PROLOG nehmen :p

http://de.wikipedia.org/wiki/Common_Lisp_Object_System
Seit 1994 ANSI-standardisiert.

DEvent schrieb:

Ist halt OOP. Wems nicht gefällt, kann ja LISP oder PROLOG nehmen :p

Klassen wie MenuDatei, MenuBearbeiten und MenuHilfe sind alles andere als OOP. Das sind so richtig typische "alles-was-ich-angreifen-kann-ist-eine-Klasse"-Designs, wenn man es denn als Design bezeichnen darf.

Typischerweise lassen sich halt Algorithmen eher schlecht in einem objektorientierten System abbilden, aber statische Methoden gibts ja auch nicht umsonst.

DEvent

volkard schrieb:

DEvent schrieb:

Klar macht man aus allem eine Klasse.
Nenn mir mal ein Beispiel wo es sich absolut nicht auszahlt es in eine Klasse zu packen.
double sqr(double x){
   return x*x;
}
wenn man das is eine klasse packen sollte, dann in double rein. das geht aber nacht. dann lieber ohne klasse.

Aha und das ganze im globalen namespace ? Was ist wenn ich meine eigene Implementation der sqr-Funktion haben will.

DEvent

Klassen wie MenuDatei, MenuBearbeiten und MenuHilfe sind alles andere als OOP. Das sind so richtig typische "alles-was-ich-angreifen-kann-ist-eine-Klasse"-Designs, wenn man es denn als Design bezeichnen darf.

Was spricht den dagegen ?
In den Ctors siehts dann so aus:

Hauptfenter()
{
    hauptframe.setMenu(new Menüs());
}

Menüs()
{
    add(new MenuDatei());
    add(new MenuBearbeiten());
    add(new MenuHilfe());
}

Man hat schnell die Übersicht, man braucht nicht die Implementation der Menüs sehen, wenn man nicht will. Wenn man doch sehen will wie das Menu Datei aufgebaut ist, geht man flott in die Klasse MenuDatei rein.

Also ich sehe nur Vorteile.

DEvent schrieb:

Was ist wenn ich meine eigene Implementation der sqr-Funktion haben will.

Dann überdeck ich die globale Version einfach in einem lokaleren Scope. Aber Funktionen ansich als Hilfsmittel für allgemeine Aufgaben sind ja kein Argument gegen Klassen, wie man z.B: auch mit static imports in Java sehen kann (auch wenn ich es deswegen nicht zwangsweise gutheiße).

Man hat schnell die Übersicht, man braucht nicht die Implementation der Menüs sehen, wenn man nicht will. Wenn man doch sehen will wie das Menu Datei aufgebaut ist, geht man flott in die Klasse MenuDatei rein.

Also ich sehe nur Vorteile.

Wie wäre es z.B: mit hochgradiger Redundanz als Nachteil? ..

Überleg einfach mal durch was sich die 3 Klassen unterscheiden:

Text, bzw. Beschreibung
Listener, der die gewählte Aktion ausführt
eventuell Icon

Langsam sollte es halt klingeln und offensichtlich werden, dass deine 3 Klassen in Wahrheit 3 Objekte sein sollten.

volkard

ich erinnere mich auch mit schrecken an
class BubbleSort:public SortAlgorithm...

Gregor

BTW: Wie macht man eigentlich folgendes, wenn man nicht OOP betreiben möchte...

Man hat einen Algorithmus, der sehr lange braucht, deshalb will man den Fortschritt durch eine Art ProgressBar visualisieren.

Im OOP-Fall würde ich mir da praktisch so ne Klasse basteln, wie volkard sie gerade mit dem Sortieren vorgeschlagen hat. Die Objekte dieser Klasse hätten dann halt einen inneren Zustand, der den aktuellen Fortschritt repräsentiert, den man von außen abfragen könnte. Wie macht man das ohne OOP? Da müsste man wohl mit Funktionen arbeiten, die Nebenwirkungen haben - wie auch die entsprechende Methode im OOP-Fall. Diese Nebenwirkungen wären aber nicht gerade lokal oder so... Wie baut man soetwas also vernünftig auf?

volkard

Gregor schrieb:

Wie baut man soetwas also vernünftig auf?

pushen statt pollen natürlich. dann bleibt der algo fast genausoschnell und der optimierer kann wegfetzen, wasimmer er will. beim pollen mußt du erlauben, daß der komplette zustand ausgewertet werden kann, auch schleifenvariablen, die eigenrlich in einem register liegen sollten. und alle lokalen variablen zu attributen zu machen ist auch durchaus unintuitiv.

Klassen sind Funktionsgruppen.
Beispielsweise sämtliche Sachen, die mit Textdateien in einem Textprogramm zu tun haben könnten in eine Klasse (also laden, speichern, löschen, ...)

ne, is falsch, das is kein oop. in OOP gibt es keine funktionen. das was du beschrieben hast nennt man auch nicht kapselung.