Wie programmiert man richtig?



  • Ich habe ein Objekt das quasi alle Objekte und Parameter die für andere Objekte interessant sein könnten enthält. Die meisten anderen Objekte referenzieren dieses Objekt. Das scheint mir eine praktische Lösung zu sein.
    Nun habe ich aber von irgendwelchen Gottobjekten gehört die scheinbar etwa das sind was ich gemacht habe. Gottobjekte sind wohl schlecht.
    Wenn ich nun auf dieses Object verzichten würde, dann bräuchte jeder Konstruktor sehr viel mehr Parameter, was mir sehr unübersichtlich erscheint. Und wenn ich irgendwann feststelle dass irgendetwas mehr Daten braucht als zuerst gedacht muss ich alles mögliche umbauen.
    Wie macht man sowas am besten?



  • Deine Überschrift ist nicht gut...

    aber zum Topic: ich denke du meinst im Hinterkopf IoC und Dependency Injection.

    Guck dir mal Unity für C# oder Hypodermic für C++ an.

    Grüße



  • @Gruum

    1. jede Methode/Funktion/Ctor sollte absolut nur die Parameter bekommen (erreichen können) die sie definitiv auch benutzt

    als Beispiel

    struct Point
    X
    Y
    Z

    wenn eine Funktion jetzt nur auf Y zugreift - darf(sollte) sie nicht den ganzen Point bekommen - viele machen da oft Ausnahmen, weil:
    -ist leichter zu schreiben
    -sieht "schöner" aus
    -könnte ja in Zukunft anders sein
    -und,und,und
    aber richtig ist es trotzdem nicht

    2. Parameter-Anzahl mit fetten Daten/Objekt-Verteilern zu reduzieren ist für schreibfaule schön - aber die so entstehenden Schnittstellen erlauben nicht mehr die Beurteilung der Komplexität ohne den ganzen Code anzuschauen

    3. die Möglichkeit einfache Tests schreiben zu können reduziert sich dadurch auch sehr stark

    Zusatz: genau so schlecht sind Singletons - man erkennt einfach nicht mehr schnell, wer mit wem welche Daten austauscht



  • @Gast3
    Das klingt zwar halbwegs Sinnvoll und ist in meinem kleinen Projekt auch sicherlich machbar. Aber wenn das ganze dann etwas komplexer wird, dann endet man doch ganz schnell in einem Urwald aus Interfaces den niemand durchblickt.



  • doch ganz schnell in einem Urwald aus Interfaces den niemand durchblickt.

    Man kann damit auch nicht erreichen das alles trivial ist
    aber man kommt trotzdem schneller in fremden Code rein wenn er mit bedacht nach diesen Vorgaben erstellt ist - eigene kleine Projekte sind keine Messlatte für irgendwas



  • Gruum schrieb:

    Ich habe ein Objekt das quasi alle Objekte und Parameter
    die für andere Objekte interessant sein könnten enthält. Die meisten
    anderen Objekte referenzieren dieses Objekt. Das scheint mir eine
    praktische Lösung zu sein.

    Das könnte sie auch sein. Aber die Frage ist viel zu allgemein - wenn
    dein Programm jetzt fertig ist und so funktioniert hast du eine gute
    Lösung gefunden. Wenn du demnächst mal einen einzigen Eingabe-Parameter
    ändern musst und dabei mehr als eine Stelle im Code ändern musst, war
    die Lösung vielleicht doch nicht so gut.



  • Wie man richtig rumproggt ist unter den Proggern auch schonmal
    umstritten.

    Meiner Erfahrung nach ist eines der größten Probleme, wenn ein
    Programmteil davon ausgeht, das ein anderer Programmteil, irgendetwas
    irgendwie macht, ohne dass diese Beziehung direkt im Code definiert ist.

    Einfacher Fehler: Statt einer Konstante wird überall direkt der Wert
    verwendet.

    Schwierigerer Fehler: Alle Module machen irgendwo if (user == admin),
    obwohl sie eigentlich alle besser eine Funktion HasPermission() hätten
    aufrufen sollen.



  • Gruum schrieb:

    Ich habe ein Objekt das quasi alle Objekte und Parameter die für andere Objekte interessant sein könnten enthält. Die meisten anderen Objekte referenzieren dieses Objekt. Das scheint mir eine praktische Lösung zu sein.

    Ist es. Wenn ich dich richtig verstehe beschreibst du hier genau das sog. Service Locator Pattern. Hat vor und Nachteile. Gibt genug Artikel dazu im Inet wenn es dich genauer interessiert.

    Gruum schrieb:

    Nun habe ich aber von irgendwelchen Gottobjekten gehört die scheinbar etwa das sind was ich gemacht habe. Gottobjekte sind wohl schlecht.

    Meiner Meinung nach sind God-Objects schlecht, ja.
    Wenn dein Objekt neben Initialisierung und Freigabe noch weitere Logik enthält, dann könnte es leicht sein dass es kein reiner Service Locator mehr ist, sondern eher ein Gob Object. Davon würde ich dann auch stark abraten.

    Gruum schrieb:

    Wenn ich nun auf dieses Object verzichten würde, dann bräuchte jeder Konstruktor sehr viel mehr Parameter, was mir sehr unübersichtlich erscheint.

    Es ist übersichtlicher und unübersichtlicher.
    Der lokale Code in den Klassen wird etwas unübersichtlicher in dem Sinn dass die Konstruktoren halt viele Parameter haben.
    Das ganze Programm wird allerdings übersichtlicher, da man viel leichter sieht wer von wem abhängig ist.

    Gruum schrieb:

    Und wenn ich irgendwann feststelle dass irgendetwas mehr Daten braucht als zuerst gedacht muss ich alles mögliche umbauen.
    Wie macht man sowas am besten?

    Während der Erstentwicklung, nervt das wirklich ein wenig. Zumindest wenn man so entwickelt wie ich. Da fliesst noch so viel Code durch die Gegend, und dann müssen schon öfters die Parameterlisten angepasst werden. Ist aber erträglich.
    Sobald der Code mal halbwegs stabil ist, ist es wurst, und die Vorteile überwiegen mMn. eher.
    Einmal alle paar Wochen/Monate wo nen Parameter dazu oder wegmachen und das durch 2-3-4-5 schichten durchzuziehen ist zwar minimal lästig, aber kein echtes Problem.

    Es gibt aber noch eine andere Lösung: mehrere kleinere Service-Locator Klassen bauen. Oft gibt es grössere "Module" die aus vielen Klassen bestehen, die oft ein sehr ähnliches Subset aus Services benötigen. Dann kann man einen Service-Locator pro Modul machen. Ist zwar auch weniger exakt als wenn jede Klasse nur das bekommt was sie wirklich braucht, aber immer noch viel exakter als ein riesiger fetter Service Locator für's gesamte Programm.



  • Rich Tigprogger schrieb:

    Gruum schrieb:

    Ich habe ein Objekt das quasi alle Objekte und Parameter
    die für andere Objekte interessant sein könnten enthält. Die meisten
    anderen Objekte referenzieren dieses Objekt. Das scheint mir eine
    praktische Lösung zu sein.

    Das könnte sie auch sein. Aber die Frage ist viel zu allgemein - wenn
    dein Programm jetzt fertig ist und so funktioniert hast du eine gute
    Lösung gefunden. Wenn du demnächst mal einen einzigen Eingabe-Parameter
    ändern musst und dabei mehr als eine Stelle im Code ändern musst, war
    die Lösung vielleicht doch nicht so gut.

    Wieso sollte die Lösung dann schlecht sein?
    Dann muss er die Änderung halt durch ein paar Schichten durchziehen.
    Und?

    Wobei ein riesiger Service Locator für das gesamte Programm eher zur Folge hat dass solche Änderungen klein werden. Bzw. der Verzicht auf den Service Locator zur Folge hat dass die Änderung grösser wird. Deswegen ist der Service Locator aber nicht generell besser. Gibt doch wohl 100x wichtigere Dinge als an wie vielen Stellen im Code er (triviale) Änderungen machen muss wenn er zusätzliche Funktionen integriert.
    (Trivial wie in "einen Parameter mehr durchschleifen")



  • hustbaer schrieb:

    Wieso sollte die Lösung dann schlecht sein?

    ich schrieb ja auch nicht "schlecht" sondern "vielleicht nicht so gut".
    Ich denke man kann das so abstrakt gar nicht bewerten.

    Alle Parameter irgendwo durchschleifen ist unpraktisch, aber die Abhängigkeit an so einen Service Locater kann ebenso unpraktisch sein (bzgl. Wiederverwendung).



  • Das hört sich so schwammig an. Wenn ein Objekt alles enthält, was irgendwie für alle interessant sein könnte, dann klingt das so, als hättest Du kein klares Design.

    Auch lange Parameterlisten sind ein Zeichen, dass da keine saubere Kapselung bzw. Aufgabentrennung implementiert ist.

    Ein Objekt hat eine Aufgabe. Es sollte in der Regel mit wenigen Parametern zur Initialisierung auskommen. Und Methodenaufrufe sollten auch wenige Parameter haben. Haben sie viele, dann ist das nicht richtig gekapselt.

    Ein Gottobjekt ist ein Objekt, welches alles macht und weiß. Also offensichtlich ein Objekt, welches mehr als eine Sache macht und weiß. Damit widerspricht das der Aussage von oben und ist damit ein Hinweis auf ungünstiges Design.



  • tntnet schrieb:

    Das hört sich so schwammig an. Wenn ein Objekt alles enthält, was irgendwie für alle interessant sein könnte, dann klingt das so, als hättest Du kein klares Design.

    Auch lange Parameterlisten sind ein Zeichen, dass da keine saubere Kapselung bzw. Aufgabentrennung implementiert ist.

    Naja...
    Beides zu vermeiden, also einerseits Objekte die viel enthalten was für viele verschiedenen Prozesse/Objekte/... interessant ist und andrerseits lange Parameterlisten... schwierig irgendwie.

    Manchmal geht das sehr schön, aber manchmal würde es das einführen von vielen verschiedenen "Blub-Dependencies" Klassen erfordern + das "umkopieren" zwischen diesen. Was dann auch nicht so schön ist.


Log in to reply