Designfrage bei Klassemodellierung

[Alaitoc]

Ich hatte gewissermaßen Glück und bei mir wurde in der Ausbildung viel wert auf sowas gelegt. Wobei ich gar nicht wissen will was ich noch alles falsch mache :3

Was man zumindest immer bei sich liegen haben sollte ist ein Buch mit Entwurfsmustern, finde ich äußerst prakisch

MfG Alaitoc

[r2c2]

Zitat von Alaitoc:

Nun jenachdem wieviele Formulararten es geben soll, bzw. in der Theorie dazukommen könnten finde ich es angenehmer wenn diese einfach an zwei definierten Stellen hinzugefügt werden.

Und ohne Factory musst du es nur an einer Stelle tun. Nämlich beim Erzeugen. Und eben nicht zusätzlich noch in der Factory. Ne Factory hat auch ihre Vorteile. Aber nicht "Einfachheit".

- Ne Abstract Factory (GoF:87) ist gut, wenn man zusammengehörige "Familien" von Objekten hat.
- Ne Factory Method (GoF:107) ist gut, wenn du in Subklassen auch subklassen einer abhängigen Klasse hast
- Ne Factory Method ohne Vererbung hat zumindest noch ne Vorteil, dass man LazyInitialization machen kann oder Objekte cacht. Außerdem hat man den Vorteil, dass man die Implementierungklasse eines Interfaces bzw. einer abstrakten Klasse von der Verwendung entkoppelt und somit zu nem späteren Zeitpunkt ändern kann. BTW: Das alles trifft natürlich auch auch die obigen Factory-Varianten zu.

Wie gesagt: Factory ist nicht schlecht. Aber dass sie einfacher oder übersichtlicher als ne stink-normale Initialisierung sein soll, sehe ich nicht.

Zitat:

Es sind reine repräsentative Klasse, die noch um Controller angereichert werden. Aber damit hat es wenig zu tun. Es geht eigentlich nur darum, ob hier eine so präzise Vererbung sinnvoll ist, oder eben eher wenige Klassen mit mehr Optionen.

Ich könnte ja alternativ zu den obigen Klassen folgendes konstruieren:

Das kommt ein bisschen darauf an, wie sich die klassen unterscheiden. Mach einfach mal folgenden "Test": Überleg dir mal den Fall, dass du nur eine Klasse hast. Wie einfach oder schwierig ist es nun, Konsistenz sicher zu stellen? Hast du viele Abhängigkeiten zwischen einzelnen Feldern, die du ansonsten verhindern könntest? Sowas ist eher gefährlich, weil es mit der Zeit zu ner Bugschleuder mutiert.

Auf der anderen Seite haben viele Klassen auch ihre Nachteile, die ich einfach auch mal in die Runde werfe:
- mehr Klassen bedeutet mehr Klassen, die man Gedanklich auseinander halten muss und nicht verwechseln darf
- Klassen die einfach auf -Ex enden sind ein Zeichen für ne falsche Herangehensweise. Das sagt nur "ich hab hier was, das kann mehr, aber was es mehr kann, kann ich nicht genau beschreiben". Wenn du keinen gescheiten Namen finden kannst, ist was konzeptionell faul.
- Mit leeren Klassen ist es ganz ähnlich. Die bringen ein Mehr an Komplexität, helfen aber nicht. Siehe hierzu auch den Artikel, den ich oben verlikt hab.
- Eine bestehende Klassenhierarchie schränkt dich auch in deinen weiteren Möglichkeiten ein. Wenn du schon abgeleitet hast, wir es schwerer nochmal anders abzuteiten. Wenn du Vererbung machst bedeutet das, dass du dir zu diesem Zeitpunkt schon Gedanken um weitere Ableitungen, etc. machen solltest.
- Vererbung wird wie Stevie schon schön zitiert hat, gerne überverwendet. Die eigentliche Vererbung ist nämlich nur ein Teil (und manche sagen der unwichtigere Teil) von dem, was du machst, wenn du ableitest. Siehe heirzu: http://www.christian-rehn.de/2010/09...-verschweigen/ Eigentlich geht es um mehr...

Zitat:

Am Besten ein Klassendiagramm erstellen und überlegen was sich noch ändern könnte, bzw. worauf man gefasst sein müsste...natürlich auch wieder Aufwand ^^

Den Vorschlag kann ich mich nur anschließen.

Zitat:

Muss mir jetzt unbedingt mal das Clean Code Buch durchlesen -- ich hab es schon ewig daheim liegen und bin noch gar nicht dazu gekommen da mal rein zu schauen...

Wenn du schon von CleanCode redest: Der oben verlinkte Artikel ist vom selben Autor und sehr zu empfehlen. Also natürlich nicht mein Blog-Artikel, sondern das pdf, über das ich da rede...

mfg

Christian

[Alaitoc]

Zitat:

Und ohne Factory musst du es nur an einer Stelle tun. Nämlich beim Erzeugen. Und eben nicht zusätzlich noch in der Factory. Ne Factory hat auch ihre Vorteile. Aber nicht "Einfachheit".

- Ne Abstract Factory (GoF:87) ist gut, wenn man zusammengehörige "Familien" von Objekten hat.
- Ne Factory Method (GoF:107) ist gut, wenn du in Subklassen auch subklassen einer abhängigen Klasse hast
- Ne Factory Method ohne Vererbung hat zumindest noch ne Vorteil, dass man LazyInitialization machen kann oder Objekte cacht. Außerdem hat man den Vorteil, dass man die Implementierungklasse eines Interfaces bzw. einer abstrakten Klasse von der Verwendung entkoppelt und somit zu nem späteren Zeitpunkt ändern kann. BTW: Das alles trifft natürlich auch auch die obigen Factory-Varianten zu.

Wie gesagt: Factory ist nicht schlecht. Aber dass sie einfacher oder übersichtlicher als ne stink-normale Initialisierung sein soll, sehe ich nicht.

Stimmt auch wieder. Ich bin jetzt von meinem Fall ausgegangen also verschiedene Klassen von Views und Models die über eine Factory erstellt werden, verknüpft oder Ähnliches. Für simples Erstellen o.Ä. ist sie sicherlich keine gute Wahl. Hast vollkommen Recht

MfG Alaitoc