Geradeliniger Programmablauf vs. Datenkapselung

[Volvagia]

Ich habe gelesen, dass ein Projektentwurf, der auf Komponenten, die immer Subkomponenten benutzen nicht vorteilhaft ist, da die Abhängigkeiten sich so schwerer elementieren lassen. Glaube das nannte sich "Top-Down-Prinzip".

Da wäre es vorteilhafter, einen Code zu verwenden, in der sich quasi ein Controller (z. B. am Anfang die main) durch das Programm "schlängelt" und die Komponenten durch Observation und Methodenaufruf vernetzt. Aber steht das nicht im Gegensatz zum Verstecken von Informationen-Prinzip? Falls ein Objekt z. B. Container (viewport) hat, wäre es möglich, dass diesen der Controller getViewport() holt und einen Container hinzufügt. Da die Informationen aber möglichst in der Klasse behalten werden sollten wäre es besser so etwas wie install(Container) zu verwenden, welches den Container am Frame hinzufügt. Dadurch könnte install auch generisch werden, falls das Interface der Klasse eine portierte Subklasse für irgend etwas anderes bekommen soll. Aber dadurch würde wieder die Wiederverwendbarkeit der Klasse leiden, da install immer auf die selbe Art hinzufügen würde. Eine Änderung von z. B. BorderLayout.NORTH auf BorderLayout.SOUTH wäre nicht möglich. Das könnte durch Vererbung gelöst werden, aber dann würde es das Liskovschen Substitutionsprinzip verletzten, da sich die Subklasse nicht mehr wie ihre Superklasse verhalten würde. Ein Controller könnte mit getViewport hinzufügen wie er wolle.

Im Endeffekt: Je mehr Regeln ich zum Design (wohl mein größtes Problem) lese, umso mehr habe ich das Gefühl, dass sich die Regeln irgendwie gegenseitig widersprechen. Aber vielleicht bin ich auch einfach nur blind. :bahnhof:

 

[Marco13]

Nimm' Liskov nicht zu ernst. Also, schon, aber man muss es richtig interpretieren. Die Definition von Wikipedia ist
Sei q(x) eine beweisbare Eigenschaft von Objekten x des Typs T. Dann soll q(y) für Objekte y des Typs S wahr sein, wobei S ein Untertyp von T ist
Ich definiere: q(x) := x ist nicht vom Typ T, oder in Java: [c]!x.getClass().equals(T.class)[/c] (ex falso sequitur quodlibet)

Je mehr Regeln ich zum Design (wohl mein größtes Problem) lese, umso mehr habe ich das Gefühl, dass sich die Regeln irgendwie gegenseitig widersprechen.

So ähnlich geht's mir auch - weniger in bezug auf Widersprüche, sondern in bezug darauf, dass es immer mehr gibt, was man zu berücksichtigen versucht. Bei mir führt das dann tendeziell eher zu philosophischen Fragen, wie der nach dem http://www.java-forum.org/allgemeine-java-themen/116618-abstraktions-overkill.html und einigen, die aus diesem Thread heraus verlinkt sind.

In Anlehnung an bestimmte Aussagen/Andeutungen und Erkenntnisse von Gerd Gigerenzer ( Max-Planck-Forum - Zusammenfassung ) würde ich fast sagen: Man macht, was man für richtig hält, und ob sich das als "gut" oder "schlecht" herausstellt, hängt von Dingen ab, die man ohnehin nicht vorhersehen kann - und wenn man ein paar mal mit immer den gleichen "unvorhersehbaren Dingen" konfrontiert wurde, bezieht man sie in Zukunft in seine Planungen mit ein (und kann dann damit leichter umgehen, aber nicht mit den anderen unvorhersehbaren Dingen, die dann auf einen zukommen ).

 

[Volvagia]

Danke mal wieder, Marco.
Also soll ich meine eigenen Fehler machen, aus den Fehlern anderer ist schwerer zu lernen.

 

[Bernd Hohmann]

Also soll ich meine eigenen Fehler machen, aus den Fehlern anderer ist schwerer zu lernen.

Ist eine gängige Vorgehensweise. Letztendlich wird ein Programm zur Wetterberechnung innen drin ganz anders aussehen als eine Lagerverwaltung. Was bei der einen Aufgabenstellung schon viel zu hoch abstrahiert ist, wird bei einer anderen Anwendung schon zu wenig sein. Selbst solche Regeln wie "nicht mehr als 1 Bildschirmseite Code per Methode/Routine" machen manchmal keinen Sinn und müssen im Kontext angewendet werden.

Man muss da für seinen eigenen Kram den richtigen Laufschritt finden. Letztendlich wird man sich nach einer Weile an die meissten Konventionen halten bzw. sie quasi neu für sich selber (Er)finden.

Bernd

 

[Marco13]

So pauschal würde ich das [EDIT: ... mit den Fehlern] nicht sagen Aber man kann zumnidest versuchen, sich damit abzufinden, dass es nicht "das in jeder Hinsicht perfekte Programm" geben kann, und versuchen, die Schwachstellen zu minimieren.

 

[Volvagia]

Danke.
Wenn ich ein altes Projekt von mir lese fallen mir oft Dinge auf, die mir so nicht gefallen und die ich verbessern/ändern will. Öfters auch wärend des Schreibens eines Projektes. Deshalb dachte ich, dass wenn ich mich direkt mit den Regeln beschäftige ich gleich Code schreibe, der mir auch von Anfang an gefällt. Dabei kümmere ich mich nichtmal um Optimierung, sondern eher nur um Lesbarkeit und nachvollziehbareres Design. Ich denke aber, dass es am Ende recht viel Zeit kostet und ein ähnlicher Code wie nach einer Optimierung heraus kommt. Vielleicht bin ich einfach zu perfektionistisch.

 

[Bernd Hohmann]

Wenn ich ein altes Projekt von mir lese fallen mir oft Dinge auf, die mir so nicht gefallen und die ich verbessern/ändern will. Öfters auch wärend des Schreibens eines Projektes. Deshalb dachte ich, dass wenn ich mich direkt mit den Regeln beschäftige ich gleich Code schreibe, der mir auch von Anfang an gefällt.

Du widersprichst Dir hier irgendwie

Wenn Du paar Projekte gemacht hast, dann hast Du zumindest für Dich schonmal irgendwelche Regeln aufgestellt wie so ein Projekt auszusehen hat und kannst das nächste Projekt zumindest schonmal mit einem Skelett bestücken (wo steigt die App ein, wie steigt sie aus, wie ist es mit den Eventhandlern gelöst, wie baue ich meine Threads?).

Das ist wie beim Kochen: wenn man bisserl Routine drin hat vergleicht man seine Kochrezepte mit anderen und entscheidet ob da eine Verbesserung dabei ist.

Dabei kümmere ich mich nichtmal um Optimierung, sondern eher nur um Lesbarkeit und nachvollziehbareres Design. Ich denke aber, dass es am Ende recht viel Zeit kostet und ein ähnlicher Code wie nach einer Optimierung heraus kommt. Vielleicht bin ich einfach zu perfektionistisch.

Irgendwann ist ein Projekt auch mal abgeschlossen. Aber wenn man nach 1-2 Jahren reinschaut und selber völlig desorientiert ist, dann hat man vorher nicht sauber gearbeitet bzw. noch nicht zu seinem Stil gefunden.

Bernd

 

[Volvagia]

Ja. Ich hab vor etwa eine Woche ein Projektchen begonnen. Als ich es anlegte war mir klar, was wo wie passiert. Aber als ich es gestern wieder geöffnet habe sah ich kein Programm sondern eigendlich nur noch eine Anhäufung von Klassen die irgendwas irgendwie machen. Wenn ich es jetzt durchsehe um rauszufinden wo ich ansetzen muss um es zu erweitern fallen mir viele Dinge auf, die ich im Nachhinein betrachtet vielleicht besser machen könnte. Ich dachte wenn ich dafür Regeln hätte, könnte ich mich eher auf das, was es zu erweitern gilt konzentrieren. Z. B. bei einer MVC-Architektur den View, falls die Ausgabe erweitert werden soll.

 

[Bernd Hohmann]

Z. B. bei einer MVC-Architektur den View, falls die Ausgabe erweitert werden soll.

MVC kam von Smalltalk, da ist das quasi in der Sprache mit drin. Ich kenne nur wenige Java-Projekte, wo MVC implementiert wurde und das Zufügen eines neuen Feldes verlief so dass man eine ziemlich lange Liste abarbeiten musste. Die Erwartungen, die in dieses Pattern gesetzt wurden haben sich imho nicht so recht erfüllt (zB. mal eben alles von AWT nach Swing und von Swing in ein Webfrontend zu migrieren).

Ich hatte früher unter AWT richtig ausgeknautschte Beans die gut in VAJ integriert waren und eine Application-Klasse dazu die das GUI-Management weitestgehend selber erledigt hat (via Namenskonventionen und Reflection) - man musste nur noch die Routine mit der Ablaufsteuerung (wo komme ich her, darf ich weitergehen und wohin gehe ich, müssen Felder neu berechnet werden?) ausfüllen und gut war. Leider sind die Sourcen bei meinem Ex-Arbeitgeber geblieben und der verdient bis heute nicht schlecht mit dem Konzept.

Bernd

 

[bygones]

Die eigenen regeln sind schön und gut, wenn man alleine in seinem Zimmer hockt. Wenn man in einem Team arbeitet bzw unter einem senior/Architekten so hilft unbedingt nicht viel.
Auch sonst denk ich gibt es regeln oder Anregungen an die man sich halten soll. Sie komplett zu ignorieren und meinen, dass man das selber lernen muss halte ich für falsch

 

[BuckRogers]

Soche Probleme möcht ich auch mal haben ^^
Aber ich bin ja noch Learner.

Wieviel Zeilen umfasst denn letztendlich so ein Projektchen?

Wollt nur loswerden, da ich diese Thematik interessant finde, dass mir das bei meinen kleinen PRojektchen auch auffällt.
Aber ich rühre die nicht mehr an ^^

Grüße