[Programmiererstammtisch] "Zum ächzenden Compiler"

[Mongke Khan]

Woran macht ihr fest/ sollte man festmachen, wenn man objektorientiert programmiert, wo die Logik hinkommt?

Also z.B. wenn ich die Klasse Auto habe. Dann macht es Sinn, alle Daten des Autos (max. Geschwindigkeit, Räder, Gewicht) da unterzubringen. Wenn ich nun eine Methode "fahren" will, warum sollte man das als Methode von Auto definieren (Auto.fahre_nach(x,y)) statt eine Methode "bewege_auto(auto)" zu schreiben?
Ich tu mich da immer noch schwer damit und komme meist irgendwann an den Punkt, wo das eine oder das andere besser gewesen wäre oder mein Code inkonsistent wird. In der Folge hab ich meist nur Datenklassen (structs in c++, bei Python öfter mal nur dictionaries) und Funktionen, die mit diesen Datenklassen was anfangen.

Ganz provokant gefragt: wozu sollte ich bei Python Klassen benutzen, statt einfach alles mit Funktionen und dicts zu lösen?

[EpicFail]

Also einer meiner Profs würde dir nahelegen, alles so generisch wie möglich zu programmieren, damit man am Ende so wenig Probleme wie möglich hätte es auszutauschen. Also das Auto würde dann zb ein Interface Driveable<T> oder so bekommen und dann die konkrete Implementierung CarDriveable : Driveable<Car> oder sowas. Ob das sinnvoll ist, hängt aber natürlich auch stark davon ab, wie komplex dann zb das Autofahren in deinem Programm modelliert werden würde.

[Shakka]

Dein Prof. hat Recht.
Interfaces sind King.

Oft wird zu sehr in Objekten gedacht und dann versucht mit Vererbung Dinge zu generalisieren. Aber wenn etwas fahren kann, dann würde ich das erst mal an ein Interface anhängen.

Der schlechtere Ansatz ist, das in der Objekthierarchie festzulegen. Dann würde das Auto vom "Fahrzeug" abstammen und wann immer etwas fahren können soll, würde dann ein "Fahrzeug" erwartet. Und dann kommt einer mit einem Pferd und dann hat man den Salat.


Ob wie viel der Fahrfertigkeit in dem Objekt selbst stecken muss, weiß ich auch nicht. Es ist ja auch denkbar, dass die Straße mehr über das Fahren weiß. Oder ob es ein Fahrt-Objekt gibt oder irgend einen statischen Glump. Also irgendwo irgendwas, das ein Driveable erwartet.

[Schlumpf]

Ganz provokant gefragt: wozu sollte ich bei Python Klassen benutzen, statt einfach alles mit Funktionen und dicts zu lösen?

Damit dein Code unübersichtlich und schwer zu warten wird.

[[VK]]

Woran macht ihr fest/ sollte man festmachen, wenn man objektorientiert programmiert, wo die Logik hinkommt?

Also z.B. wenn ich die Klasse Auto habe. Dann macht es Sinn, alle Daten des Autos (max. Geschwindigkeit, Räder, Gewicht) da unterzubringen. Wenn ich nun eine Methode "fahren" will, warum sollte man das als Methode von Auto definieren (Auto.fahre_nach(x,y)) statt eine Methode "bewege_auto(auto)" zu schreiben?
Ich tu mich da immer noch schwer damit und komme meist irgendwann an den Punkt, wo das eine oder das andere besser gewesen wäre oder mein Code inkonsistent wird. In der Folge hab ich meist nur Datenklassen (structs in c++, bei Python öfter mal nur dictionaries) und Funktionen, die mit diesen Datenklassen was anfangen.

Ganz provokant gefragt: wozu sollte ich bei Python Klassen benutzen, statt einfach alles mit Funktionen und dicts zu lösen?

auto.fahreNach(x,y) ist im Grunde das gleiche wie dein bewegeAuto(auto). Ersteres übergibt das Object implizit, während letzteres explizit übergibt (bei Python wird ja in der Methodendeklaration das Objekt explizit deklariert). Daher ist erste Methode eindeutig zu bevorzugen, vorallem, wenn du das Object auch noch im MethodenNamen rein machst.

Dein Prof. hat Recht.
Interfaces sind King.

Oft wird zu sehr in Objekten gedacht und dann versucht mit Vererbung Dinge zu generalisieren. Aber wenn etwas fahren kann, dann würde ich das erst mal an ein Interface anhängen.

Der schlechtere Ansatz ist, das in der Objekthierarchie festzulegen. Dann würde das Auto vom "Fahrzeug" abstammen und wann immer etwas fahren können soll, würde dann ein "Fahrzeug" erwartet. Und dann kommt einer mit einem Pferd und dann hat man den Salat.


Ob wie viel der Fahrfertigkeit in dem Objekt selbst stecken muss, weiß ich auch nicht. Es ist ja auch denkbar, dass die Straße mehr über das Fahren weiß. Oder ob es ein Fahrt-Objekt gibt oder irgend einen statischen Glump.

Ich würde sogar noch weiter gehen und das Interface einfach nur "Moveable" und die Methode "move" nennen. Sollte es nötig sein, dass du beispielsweise einen Pegasus hast, der unterschiedliche Bewegungsmodi hat, kann dem Auto eine Strategie zugewiesen werden. In der Regel, ist aber Vererbung ausreichend.

Informationen der Straße sollten imo auch lieber der Methode beim Aufruf übergeben werden.

[Snup]

Als C#-Entwickler sage ich, alles gehört in Klassen (oder Interfaces). Das ist ja überhaupt nur der Punkt an der ganzen Objektorientierung.

[Mongke Khan]

Also zusammengefasst: Daten in Klassen, Logik in Interfaces

[Snup]

Interfaces enthalten selbst keine Logik, sie sagen Klassen, welche Logik sie enthalten sollen.

[Mongke Khan]

Das meinte ich
Also meine bisherige Sammlung an Einzelfunktionen würde ich halt in sinnvolle Interfaces gruppieren und für jede Klasse ausimplementieren.

[alpha civ]

Woran macht ihr fest/ sollte man festmachen, wenn man objektorientiert programmiert, wo die Logik hinkommt?

Also z.B. wenn ich die Klasse Auto habe. Dann macht es Sinn, alle Daten des Autos (max. Geschwindigkeit, Räder, Gewicht) da unterzubringen. Wenn ich nun eine Methode "fahren" will, warum sollte man das als Methode von Auto definieren (Auto.fahre_nach(x,y)) statt eine Methode "bewege_auto(auto)" zu schreiben?
Ich tu mich da immer noch schwer damit und komme meist irgendwann an den Punkt, wo das eine oder das andere besser gewesen wäre oder mein Code inkonsistent wird. In der Folge hab ich meist nur Datenklassen (structs in c++, bei Python öfter mal nur dictionaries) und Funktionen, die mit diesen Datenklassen was anfangen.

Ganz provokant gefragt: wozu sollte ich bei Python Klassen benutzen, statt einfach alles mit Funktionen und dicts zu lösen?

Zu deinem Autobeispiel: ganz klar keine Methode "fahre_nach". Grund: Andernfalls hättest du zwei Gründe, deine Autoklasse zu ändern. Einmal, um Datenfelder hinzu zufügen oder zu ändern/entfernen. Und zweitens eine Änderung der Bewegungslogik.
Ob diese Bewegungslogik in eine Methode oder eigene Klasse wandert hängt von der Wahl der Programmiersprache ab. Was man im Prinzip hat ist eine Strategie, wie sich das Auto bewegen kann. Möglicherweise ist für spezielle Autos eine andere Bewegungslogik erforderlich. Trennt man Bewegungslogik von den Autodaten, dann hat man mehr Freiheiten. (Siehe "Single Responsible Principle".)

Allgemein: Ein Objekt im objektorientierten Sinne kapselt Verhalten, im Gegensatz zu einer Datenstruktur, welche Daten kapselt. Ein Objekt hat dann auch keine Daten, sondern einen Zustand, der ausgelesen und ggf. verändert werden kann über öffentliche Methoden. Klassen bieten die Möglichkeit, diese Methoden an einen Ort zu implementieren, anstatt das diese über mehrere Dateien hinweg verstreut sind. Mit dem dict und Funktionen hast du das Problem, dass in irgendeine Date irgendwo vielleicht doch noch eine Funktion existiert, die den Zustand dieses dicts verändert. Das erhöht nur unnötig die Komplexität und das Bugpotenzial.

[alpha civ]

Das meinte ich
Also meine bisherige Sammlung an Einzelfunktionen würde ich halt in sinnvolle Interfaces gruppieren und für jede Klasse ausimplementieren.

In statisch typisierten Sprachen sind Interfaces (wenn unterstützt) ein gutes Mittel um echte Unittests schreiben zu können.
Um das Beispiel mit der Bewegungslogik zurückzukommen: angenommen, du hast eine andere Klasse (nennen die wir mal C), die diese Logik verwendet (in Java/C# wäre das in einer Klasse gekapselt, nennen wir das einfach mal MoveStrategy). Die Methode foo von C macht was MoveStrategy und noch etwas anderes. Um einen echten Unittest für foo schreiben zu können, muss man sich um die Abhänigkeit zu MoveStrategy kümmern. Man will nur foo testen, aber nicht auch gleichzeitig die MoveStrategy, sonst wäre das ein Integrationtest.

Abhilfe schafft hier Dependency Injection: Die Instanz von MoveStrategy wird nicht in foo erzeugt, sondern dem Konstruktor als Parameter übergeben und dann in foo verwendet. Dieser Parameter hat aber nicht den Typ "MoveStrategy", sondern z.B. IMoveStrategy und ist ein Interface. MoveStrategy implementiert dieses Interface. Jetzt kann man einen Unittest zu foo schreiben. Man braucht nur eine Klasse FakeMoveStrategy zu schreiben, die ebenfalls IMoveStrategy implementiert und im Test dann dem Konstruktor übergeben wird.

In Python muss man den Weg über Interfaces nicht gehen (gibt ja auch keine), hier reicht Ducktyping aus.

[alpha civ]

Interfaces enthalten selbst keine Logik, sie sagen Klassen, welche Logik sie enthalten sollen.

Nein, dass tun sie nicht. Sie geben nur Signaturen vor.

[Schlumpf]

Gerade 3 Stunden versucht ein Programm zum laufen zu bringen. Und woran lag es? Das Programm mochte nicht dass im redhat-release das falsche drinnen steht. Aber eine Fehlermeldung ausgeben wäre ja auch zu viel verlangt.

[Frozen]

cmake

-- Checking for CUDA backend
-- Checking for CUDA backend - not found
-- Checking for OpenCL backend
-- Found OpenCL: /usr/.../cuda/cuda-11.4.3/lib64/libOpenCL.so
-- Checking for OpenCL backend - found

[Mr. X]

Ich habe eine natürliche Allergie gegen cmake... Es funktioniert, solange man die magischen und undokumentierten Parameter kennt, die man auf jeder Maschine setzen muss (also außer auf der desjenigen, der das cmake-Skript aufgesetzt hat).