OOP
-
Stromberg schrieb
Wenn ich einen Code richtig OOP haben möchte, darf ich dann gar keine Funktion mehr haben? Nur noch Objekte und Methoden?
Nö, denn dann must du erst mal an der Windows API vorbei :->
Generell würde ich sagen, dass man OOP mit Sinn und Verstand einsetzen sollte und nicht alles und jedes in eine Klasse packen sollte. Man kann zwar alles in eine Klasse packen wie, dies in Java der Fall ist, aber ob dies Sinn macht ist eine andere Sache. OOP schützt nicht vor einem schlecht programmierten System.
Denn mit der OOP will man ja im Endeffekt nur eine gute Datenkopplung erreichen, doch ich kenne einen Fall wo dies massiv in die Hose ging.
Ein Kollege an der Uni hat mittels eines Skriptes ein C++Framework zur Berechnung von Bewegungen erzeugt. Dabei erzeugte er mehrere hunderte Klassen erzeugte, für jede möglich rudimentäre Bewegung legte er eine seperate Klassen an. Und da ihm irgentwann die Namen ausgingen, ging er zu kryptischen Bezeichnungen über. Und da er ja ein einheitlichen Modell für alle Bewegungen brauchte, hat er sämtliche Daten mittels Array addressiert. Das System funktionierte zwar, aber da er das objektorientierte Design brutalst durchzog, hat im schlichtweg das komplette Programm versaut. Weiterarbeiten kann man mit diesem Programm nicht. Und dass musste ich einen Prof. erklären.
Summa sumram, der Kollege hat einen weiteren Meilenstein zu der Geschichte: "My Code is my Castle" (http://www.javatux.de/J4L/AntiRules.html) geschrieben.
-
Stromberg schrieb:
Wenn ich einen Code richtig OOP haben möchte, darf ich dann gar keine Funktion mehr haben? Nur noch Objekte und Methoden?
MfG
StrombergSolange du "OOP" nicht als etwas definierst was total plem ist: Nein.
Dinge wie sin/cos/sqrt/... sind nunmal Funktionen, und es macht überhaupt garkeinen Sinn diese als "statische Methoden" einer Klasse zu "tarnen".
-
Es kommt immer auf den Kontext an ...
Bei kryptografischen Anwendungen macht sowas durchaus Sinn. Jedes mal ein neues Objekt erzeugen, nach Verwendung überschreiben und löschen.
Das ganze mit statischen Funktionen zu kapseln ist nicht verkehrt.
-
Stromberg schrieb:
Wenn ich einen Code richtig OOP haben möchte, darf ich dann gar keine Funktion mehr haben?
Nimm Smalltalk oder programmiere C++ so wie es vorgesehen ist: als Hybridsprache.
-
Stromberg schrieb:
Wenn ich einen Code richtig OOP haben möchte, darf ich dann gar keine Funktion mehr haben? Nur noch Objekte und Methoden?
Wenn du OOP wie es in den Lehrbüchern beschrieben wird nimmst, dann ja. Und nach den Lehrbüchern würde man auch grundsätzlich alle Versuche OOP in Prozeduralen Sprachen zu verwenden als Unsinn abtun. Ja, letztere Meinung unterstütze ich auch weitgehen (Da zu moderner OOP [damit meine ich neuer als 10 Jahre] auch sowas wie Datenkapselung und Geheimnisprinzip gehört; ich weiß das man ähnliches wie OOP in z.B. C schreiben kann, ich sehe dort aber noch immer Unterschiede zwischen "OOP ähnlich" und "OOP").
Was aber nicht das Geheimsnisprinzip verletzt und in C++ der vorzuziehende Weg ist, alle ich sage mal "Hilfsfunktionen", die keine Ahnung von der Klassenimplementierung erfordern, aus dem Objekt auszulagern [Dies macht z.B. auch die STL weitgehen]. Damit vermeidest du unter anderem unnötig große Objekte.
cu André
-
geheimnisprinzip? so etwas wie pimpl bekommt man unter C auch hin.
-
Hier noch ein interessanter Bericht (finde ich):
How Non-Member Functions Improve Encapsulation, Dr. Dobbs, Feb. 2000
http://www.ddj.com/cpp/184401197Simon
-
camping wagon schrieb:
geheimnisprinzip? so etwas wie pimpl bekommt man unter C auch hin.
Okay, das Body-Handle Idiom habe ich tatsächlich übersehen. Wobei es andere Prozedurale Sprachen gibt die so etwas nicht unterstützen (Hast aber in sofern recht das mein Argument für C entkräftet ist).
cu André
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
ob isch stromberg das hier noch durchliest;)
