OOP - Endloses gewrape und endlose Verschachtlung von Kalssen
-
H4ck3r schrieb:
Ich bin Ex-ITler und habe dieses OOP auch gehasst wie die Pest. Sich da durch den Code zu fummeln ist echt das Letzte.
Lag das wirklich an OOP, oder an den Programmierern? Ich könnte per se genau das Gegenteil von nicht-OOP bei großen Projekten behaupten, oder bei nicht verstandenen OOP (C mit Klassen).
H4ck3r schrieb:
Es ist eben in der Praxis selten alles gut dokumentiert und oft haben da schon viele Köche in den Brei gespuckt, bevor man selbst mal ran muss.
1. Gute Dokumentation habe ich bis heute noch in KEINEM Projekt erlebt. Entweder einer verlangt es für jeden Codeschnipsel, obwohl es in einer C++ Referenz gut erklärt wird, oder es ist so stark veraltet das es nichts bringt (wenn nicht gar nicht existent).
2. Code kann dennoch lesbar oder gut strukturiert sein (Egal ob OOP oder nicht, egal ob mit Schichtentrennung oder nicht). Normalerweise sollte einem bei OOP sogar der konkrete Code hinter einer Implementierung solange egal sein, wie man nicht genau an dieser Implementierung etwas ändern muss. Dafür sind Schnittstellen doch gerade dar.
H4ck3r schrieb:
So sinnvoll OOP oft sein mag. Ich habe es in der Praxis gehasst.
Ich habe bislang jedenfalls noch keine bessere Alternative erlebt (Und ich habe nicht mit OOP angefangen).
-
Es gibt da meiner Meinung nach einige fundamentale Missverständnisse was die objektorientierte Programmierung angeht.
Auch in der heutigen Zeit fängt man meistens an mit rein imperativer Programmierung. Wenn man mit Java anfängt hat man da zwar Objekte, aber man setzt nicht um was der Grundgedanke von OOP ist. Man programmiert immer noch nach dem imperativen Ansatz. Eigentlich sollte man zum Einstieg in die Programmierung erstmal ein paar Wochen Problemstellungen nur auf dem Papier mit Objekten modellieren. Dann würde OOP den Leuten so viel leichter fallen. Und die meisten Leute die meinen sie hätten OOP verstanden haben es doch nicht.
Jetzt geht man also an ein Stück Software-Code ran und möchte diesen verstehen. Aber nirgendwo passiert etwas. Man geht von Objekt zu Objekt, alle deligieren irgendwas oder erstellen neue Objekte, aber vom rein imperativen Ansatz her geschieht einfach nichts. Und das ist der Denkfehler. Es geschieht sehr wohl etwas. Aber nicht nach dem imperativen Ansatz. Das ist Objektorientierung. Man darf den Code nicht nach dem imperativen Ansatz her lesen (immer in jede tiefer verschachtelte Funktion reinspringen ...) sondern muss verstehen was die Objekte grundsätzlich an Funktionalität bereitstellen. Das kann zunächst über eine sinnvolle Benamsung (auch das können nur wenige Programmierer wirklich gut) erkenntlich gemacht werden.
Wenn man von einer Software nur die Klassennamen durchließt sollte man schon eine Ahnung haben was die Software tut (ohne sie vorher zu kennen). Ansonsten ist dein Projekt Dreck. Datenmodell scheiße -> OOP scheiße -> Software scheiße.
Und das ist auch das Problem des Autors dieses Threads. Du hast den OOP Ansatz (wie so viele andere) noch nicht voll begriffen. Aber wenn man noch ein bisschen übt wird das schon. Da kann ich nur empfehlen viel zu lesen und sich z.B. mal mit der Clean Code Developer "Bewegung" auseinanderzusetzen.