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.