The Ripper schrieb:
Hier meinte ich, dass man keine Properties hat. (versehentlich lokal geschrieben)
Gut. Properties sind auch mehr syntaktischer Zucker und ich hatte ja darauf auch hingewiesen.
Ändert aber nix an der grundsätzlichen Thematik die ich mit dem Beispiel verdeutlichen wollte. Nämlich das jede Methode Zugriff auf alle Attribute des Objektes hat. Egal, ob sie die nu zwingend braucht oder nicht.
The Ripper schrieb:
Du sagst: Keine globalen Variablen wegen höherem Risiko von unübersichtlichen Änderungen (zu hoher Scope).
Ich sage: Keine globalen Variablen sind Teil des Prinzip der OOP.
Naja. Gerade das Singleton-Pattern wird ja gerne mal dazu benutzt, um globale Zustände zu behandeln.
Außerdem sage ich ja nicht, dass (programm-)globale Variablen zu OOP gehören. Ich sag nur, dass Objektattribute eben im Context eines Objektes auch "global" sind. Wie oben gesagt: Jede Methode kann auf jedes Attribut zugreifen. Auch wenn es diesen Zugriff eigentlich gar nicht braucht.
The Ripper schrieb:
Und: Wenn du zu dem obigen Beispiel keine gute Lösung findest, dann ist sowohl meine Sicht als auch deine Sicht optimal befriedigt.
Nochmal: Es geht hier nicht zwingend darum es besser zu machen oder solche Sachen als "schlecht" anzusehen.
Genauso wie programm-globale Variablen nicht per se schlecht sind. In kurzen Programmen machen sie sehr wohl oft Sinn, weil dann eine Vermeidung das Programm eher unnötig kompliziert und damit wieder fehleranfälliger machen (eigentlich etwas, was man mit der Nichtverwendung von globalen Variablen vermeiden will).
Und wenn eine übersichtliche Klasse ist, wird man da mit Attributen auch kaum in ernsthafte Probleme laufen.
Das einzige, worauf ich hinweisen möchte, dass man sich darüber im Klaren sein muss, dass Objektattribute eben potentiell die gleichen Problemklassen haben wie globale Variablen. Wenn man sich dessen bewusst ist, vermeidet man ja vielleicht z.B. irgendwie Monsterklassen zu schreiben, sondern teilt das auf. Alternativ kann man Klassen auch mit Traits modularisieren.
Du sagst ja selbst, dass gutes OOP-Design sich ja auch dadurch auszeichnet. Aber warum ist es gut? Eben u.a. deshalb, weil sonst objekt-globale Zustände ein größeres Fehlerpotential haben.
The Ripper schrieb:
Du beklagst dich im Prinzip darüber,...
Nochmal: Ich beklage mich nicht darüber. Ich weise nur darauf hin!!!
The Ripper schrieb:
Zusätzlich bist du der Meinung, dass OOP für einige Anwendungen sehr ungünstig ist, da das Prinzip der OOP beschränkend wirkt.
Nein. Das habe ich so nicht gesagt. OOP, funktionale Programmierung, Logisch-deklarative Programmierung, prozedurale Programmierung usw. sind ja lediglich verschiedene Ansätze, um ein Problem zu lösen. Und für manche Problemklassen ist aber ein bestimmtes Paradigma besser geeignet als ein Anderes.
Ein GUI-Framework ist z.B. geradezu prädestiniert dafür, dass in OOP zu implementieren.
Bei anderen Dingen, bei dem ich beispielsweise ne einfache Parallelisierung haben möchte ist vielleicht ein funktionaler Ansatz besser, da hier wegen Vermeidung von Zuständen eine Parallelisierung sehr viel einfacher ist und teilweise ja automatisch vom Compiler vorgenommen wird.
Und warum sollte ich mir dann die Vorteile bestimmter Paradigmen nicht zunutze machen und das mischen?
