Prinzipfrage: Wie hält man's mit OOP

[MaBuSE]

Zitat von QuickAndDirty:

...seit dem mache ich keine QuickAndDirty(mein Name) Lösungen mehr egal wie klein das Programm auch sein mag.

Man kann auch in OOP QuickAndDirty programmieren und man kann auch mit prozeduralem Ansatz sauber strukturiert programmieren. Das hat nichts mit dem OOP Ansatz zu tun, sondern nur mit der eigenen Struktur und Disziplin.

[negaH]

Zitat:

Ich denke in Bezug auf Erweiterbarkeit ist OOP eigentlich besser.

Nur oberflächlich betrachtet stimmt dies. Ich kann dir Beispiele nennen bei denen die "Erweiterbarkeit" von Klassen auf Grund der Regeln der OOP dazu führen musst das Monster-Klassen entstehen. Also Klassen mit über 300 Methoden. Das ist kontraproduktiv und eben nicht erweiterbar. Denn bei jeder Änderung wird das komplete Objekt verändert, was aber wenn das eine Basis Klasse ist und durch die Änderungen defakto alle abhängigen Klassen ständig neu kompliert werden müssen ? Prozedural hätte man einfach ein neue Prozedure in die Unit oder eine andere Reingepackt. Hauptsache diese Prozedure benutzt die gleichen Scnittstellen wie alle anderen Prozeduren.

Wie gesagt, erstmal soll uns die OOP Arbeit einsparen, und zwar indem man mit ihr ein identisches Problem nicht mehrmals prozedural löst sondern einmalig als Klasse zusammenfasst und wiederverwendet für andere Klassen. Man reduziert also die Komplexität des Problems durch die OOP und damit die Anzahl an Sourcezeilen. Wenn also ein Projekt per OOP mehr Sourcezeilen benötigt als Prozedural dann stimmt da was nicht vom Konzept her. Natürlich alles aus der Sichtweise heraus das wir die freie Entscheidnung überhaupt haben. Oft mß man per OOP oder prozedual programimieren weil man nicht die Manpower hat, nicht die richtigen Werkzeuge, weil es hoch-portabel belieben muß etc.pp.

Gruß Hagen

[MaBuSE]

Zitat von negaH:

Denn es nützt nichts sich mit den anderen Fragen zu quälen wenn man noch nicht weiß ob per OOP überhaupt ein Nutzen für das Projekt entsteht. Keinen Nutzen habe ich wenn per OOP 30mal mehr Source anfällt, alles viel kompilizierter wird als es real ist, OOP soll vereinfachen.

Da ist was wahres drann.

Ich kenne einen Entwickler, der sollte ein einfaches kleines OOP Programm schreiben.
In dem Programm sind alle Techniken, die so gelehrt werden verwirklich.
Das Programm besteht aus einer kleinen GUI. In der GUI ist alles gegen Interfaces programmiert.
Sämtliche Objekte werden aus einer anderen Assebly mit sogenannten Factories erzeugt.
In einer anderen Assembly werden dann die Objekte implementiert. Im Hintergrund ist ein relativ großes Objektmodel entstanden, da jede Eventualität versucht wurde zu berücksichtigen. Es wurde ein "GrundObjekt" geschrieben, davon wurde ein etwas spezialisierteres Objekt abgeleitet, davon wieder eins und dann irgendwann das Objekt welches benutzt werden soll. Es entsteht der Eindruck es wurde nur des Ableitens Willen Abgeleitet, da die Objektebenen dazwischen nicht verwendet werden.
Bei der Gelegenheit wurde dann noch die ELIB (MS Enterprise Lib) verwendet und um eigene Funktionalitäten erweitert.
Die Anwendung ist eigentlich relativ klein, aber der komplette Quellcode ist rießig.
(Der Speicherverbrauch zur Laufzeit leider auch)
Das Programm wird von den Benutzern nur ungern eingesetzt, da es sehr schwerfällig, Speicherintensiv und langsam ist.

Was will ich damit sagen:
Man kann es treiben und man kann es übertreiben.

An Stellen wo es Sinn macht, sollte man die bekannten Techniken (OOP, MultiTier, Patterns, ...) verwenden.
Aber man sollte nicht nur der Technik Willen die Technik verwenden.

Wenn die Technik einen Nutzen verspricht, dann sollte man sie verwenden.
Wenn die Technik mehr Aufwand als Nutzen bringt, sollte man es überdenken.

[DeddyH]

@MaBuSE: Dein Beispiel erinnert mich irgendwie an die Hammer-Factory

[MaBuSE]

Zitat von DeddyH:

@MaBuSE: Dein Beispiel erinnert mich irgendwie an die Hammer-Factory

Cool, das kannte ich ja noch gar nicht. Ich werde es mal an denjenigen weiterleiten

[Olli]

Hi,

ich bedanke mich erstmal bei allen Diskussionsteilnehmern.

Der "alte Hase" ist leider nicht sonderlich gut in OOP, der Rest des Teams aber eigentlich schon. Prinzipiell hätte ich ja auch nichts dagegen, wenn das Interface nach außen funktional gestaltet wäre und statt Instanzen halt Handles benutzt (die dann intern auf Instanzen mappen ).

Eigentlich bin ich inzwischen sogar entschlossener als zuvor es OOP zu machen. Ansonsten würden wir es später bereuen.


Danke nochmals.

[Hansa]

OOP-Anteile bei mir (grob geschätzt) :

TP 5.0 : 0 %
TP 5.5 : 2 %
BP 7.0 : 10 %
usw.

Delphi : nicht OOP-Anteil : ca. 5 %

OOP ist aber auch nicht einfach nur ein Schlagwort. IMHO müsste die Frage aber eher so lauten : "Welche triftigen Gründe gibt es, etwas nicht gleich mit OOP zu machen ?".

[MaBuSE]

Zitat von Hansa:

OOP ist aber auch nicht einfach nur ein Schlagwort.

Was ist denn für Dich OOP?

Wenn jemand ein TForm benutzt und dort einen TButton benutzt um dann sein Programm auszuführen, was wiederum prozedural aufgebaut ist, nenne ich nicht unbedingt OOP.
Wenn jemand eigene Klassen baut, in denen alle Methoden static sind (class procedure), um sie dann wie normale Prozeduren aufzurufen, nenne ich das auch nicht unbedingt OOP.
Wenn jemand in C# einen string verwendet oder einen Integer, so ist das für mich auch kein OOP, obwohl der Integer ja ein Objekt ist.

[Hansa]

Zitat von MaBuSE:

..nenne ich das auch nicht unbedingt OOP.

Ich auch nicht. Bei mir fängts mit Form-Inheritance an. Habe dementsprechend nur 2 Forms, die tatsächlich TForms sind (für Ein- und Ausgabe). Infolgedessen befinden sich neu eingeführte Variablen und Methoden vornehmlich in der protected-Sektion der Deklarationen. Es sollen eben immer nur neue Sachen dazukommen, die alten aber auch benutzt werden können. Infolgedessen ist auch oft override zu finden und in den Prozedur-Rümpfen inherited. Bei den Komponenten gehts dann weiter. Habe da einen ganzen Satz eigener, überwiegend von TEdit abgeleitet, um nicht jede Falscheingabe behandeln zu müssen. Die geht erst gar nicht. Rein prozedural bleibt wirklich nur eine Unit übrig die solche Funktionen/Prozeduren enthält : netto, brutto, lb, rb, zentriert usw.

[Olli]

Zitat von MaBuSE:

Wenn jemand in C# einen string verwendet oder einen Integer, so ist das für mich auch kein OOP, obwohl der Integer ja ein Objekt ist.

Das ist übrigens das putzige an C++. Formal ist ein Integer kein Objekt, aber defacto schon, weil man im Grunde jeden Aspekt eines Integers in einer eigenen Klasse nachbauen kann.