OOP Design, gibt es Regeln?
Hallo Zusammen,
Die Frage vorab: Wann wird eine Klasse erzeugt und wie tief Atomar beschrieben?
Ich habe mittlerweile das zwölfte Buch über C# und OOP gekauft mit
der Hoffnung, wenigstens eine Richtung zu bekommen wie Klassen
designt werden. In den Büchern wird immer nur die Syntax beschrieben.
Das hängt mir mittlerweile zum Halse heraus.
Gibt es für Klassen-Design irgendwelche Regeln wie z.B. bei SQL.
Sind euch irgendwelche Bücher, am besten Deutschsprachig bekannt
zu diesem Thema.
An einem kleinen Beispiel will ich meinen Schmerz visualisieren:
Ich habe eine Adresse mit den Feldern:
AdressID, Firma, Zusatz1, Zusatz2, Zusatz3, Strasse, HausNr, PLZ, Ort.
Jede Adresse hat 1:n Ansprechpartner mit den Feldern:
PartnerID, AdressID, Namen, Email, Zuständigkeit.
Für die Ansprechpartner ist es selbstverständlich eine neue Klasse zu bilden.
Bei der Adresse stellt sich die Frage: Was mache ich mit den Feldern
Zusatz1-Zusatz3. Die meisten Adressen benötigen Zusatz1-Zusatz3
nicht. Erzeuge ich dafür eine neue Klasse "Adresszusatz" und binde
diese per ArrayList in die Klasse "Adresse.Anschrift" oder
hänge ich die Felder einfach in die Klasse "Adresse.Anschrift".
Ebenso stellt sich die Frage mit dem Ort und der PLZ.
Man könnte das validieren der PLZ zum Ort ebenfalls in einer Methode
einer eigenen Klasse "Adresse.Anschrift.Ortschaft" sauber verpacken.
Wenn ich die Adresse so Atomar zerlege, habe ich deutlich mehr Arbeit.
Aber was ist der tatsächliche Nutzen? Wie kann man das fassen?
Im Übrigen, die Klasse "Adresszusatz" würde beim Speichern in der DB
eine weitere Tabelle voraussetzen, welche sich lesend und schreibend
negativ in der Performance auswirken würde, wegen dem zusätzlichen Join.
Somit komme ich zum dem Entschluß "verwende eine OO-Datenbank,
dann kannst Du schön die Klassen modellieren. Verwendest du aber
ein DBMS, dann berücksichtige die Antwortzeiten der DB"
Mit der Hoffnung das sich jemand auf dieses Thema mit mir einläst,
grüße ich Euch.
Kostas
allgemein ist zu sagen schau dir an wie MS das handhabt mit hilfe der doku kannst du eine menge über OO lernen
Wir Arbeiten eigendlich nicht wir nehmen nur das geld
Hi Kostas,
das Ganze ist doch ein Datenbankproblem. Schon dort ist es entsprechend gelöst ( über Tabellen und verknüpfte Daten).
Ich weiß nicht was du für Bücher gekauft hast, aber waren die von Scott Meyers dabei ( Effective C++; More effective C++, gibt es auch in deutsch)? Der geht schon auf Designdetails ein.
Mit der Erfahrung wächst auch das Designverständnis ( sprich man merkt, wenn etwas unhandlich ist). Und man muss unterscheiden zwischen Arbeitsaufwand und Wartungsaufwand.
Meiner Meinung nach ist, neben vernüpftigem Design, die Kommentierung des Codes viel wichtiger.
Viel Spaß
Detlef
Hallo deti61,
von Scott Meyers habe ich noch keine Bücher.
Ich komme aus der Delphi-Ecke und habe bis jetzt
mich nicht um OOP gekümmert.
Mit dem Umstieg auf C# möchte ich einen radikalen Schnitt
machen. Ich versuche zu verstehen was die Magie von OOP ist
und wie ich diese anwenden kann.
Ich denke, fehler im KlassenDesign sind genauso verhärend
wie beim proceduralem Programmieren.
Ich möchte es in Zukunft besser machen und suche dafür
irgend welche erkentnisse.
Gruß Kostas
Hallo Kostas,
Ich habe mittlerweile das zwölfte Buch über C# und OOP gekauft mit der Hoffnung, wenigstens eine Richtung zu bekommen wie Klassen designt werden.
Klassen werden ja nicht in der OOP-Phase designt, sondern - wie das Verb schon andeutet - in der OOD-Phase. Du müsstest dir also besser Bücher über OOA und OOD kaufen.
Wenn ich die Adresse so Atomar zerlege, habe ich deutlich mehr Arbeit. Aber was ist der tatsächliche Nutzen? Wie kann man das fassen?
Wenn du Klassen "ausnormalisierst" ist das genauso tötlich, wie eine Datenbank komplett auszunormalisieren. Wann man nomalisiert und wann nicht lernt man bei Klassen genauso wening aus Büchern sondern aus Erfahrung wie bei Datenbanken.
Somit komme ich zum dem Entschluß "verwende eine OO-Datenbank, dann kannst Du schön die Klassen modellieren. Verwendest du aber ein DBMS, dann berücksichtige die Antwortzeiten der DB"
Das Klassendesign sollte (wo nötig) von der konkreten Speicherform abstrahieren. Das Klassenmodell kann (und wird) also vom DB-Modell abweichen.
herbivore
Generell kann man solche Design-Fragen nicht beantworten, ohne die Anforderungen an die Software zu kennen.
Nehmen wir mal als Beispiel dein Problem mit den Adresszusätzen. Du fragst nach dem Vorteil: Wenn du die Zusätze als eigene Objekte implementierst, dann ist der Vorteil die Möglichkeit beliebig viele Adresszusätze zu definieren. Baust du den Zusatz direkt als Member in die eigentliche Klasse, dann ist die Zahl und der Inhalt fix.
Das sagt aber noch nicht über "besser/schlechter" aus. Generell gilt: Einem System mehr Funktionalität zu geben als aktuell benötigt hat immer zwei Seiten:
- das System ist tendenziell auf "Erweiterungen" vorbereitet
- mehr Code
- höhere Komplexität und damit verbundener höherer Wartungsaufwand
Das ähnelt der Frage: Ist es für mein Haus besser ein Ziegel- oder ein Holzdach zu haben. Die Antwort ist eben: "Das kommt darauf an.": Wieviel Geld und Zeit hast du für den Hausbau, wie ist die Witterung, etc..
Eine Design-Bewertung erfordert neben der angedachten Implementierung immer auch die Anforderungen und auch eine Risiko-Bewertung, inwiefern sich Anforderungen erweitern oder als falsch erweisen können können.
Denn eines ist sicher: Keine Software wird 1:1 umgesetzt wie zu Beginn geplant.
Das gesagt gilt auch für den Einsatz von Design-Patterns. Die Verwendung von Patterns hat erstmal nix mit der Design-Qualität zu tun. Auch hier kann man leicht ein System bauen, welches gemessen an den Anforderungen "over-patterned" ist. Fowler hat selbst einen Artikel dazu veröffentlicht. Die Flexibilität, wie sie eigentlich alle Patterns versuchen zu schaffen, wir immer mit einem initialen Mehr an Code und Komplexität erkauft. Die Frage ist nur, wann der "return of invest" eines Patterns ist. Oft hat man ihn sofort, manchmal viel später, manchmal nie.
Nur Flexibilität die auch genutzt wird, ist auch ein Kostenvorteil. Nutze ich sie nicht, war das Pattern unnötig eingesetzt und hat nur Kosten verursacht.
Ein gutes Design ist immer preiswert, und zwar bis zum Ende des Lebenszyklus der Software, also inklusive Wartung/Erweiterung über mindestens 5-10 Jahre.
Software mit schlechtem Design geht meist schon nach kurzer Zeit in die Verottungsphase über.
Wann es eindeutig auf der Hand liegen würde, wie man Software strukturiert und entwirft, bräuchte man keine Programmierer mehr. Man würde einfach ein Programm schreiben, dass diese Regeln implementiert und könnte damit fortan jede beliebige Software automatisch erzeugen lassen. Nur ein paar "Parameterangaben" wären noch nötig. Es gibt natürlich Leute, die schon seit längerem daran forschen, diese Vision wirklichkeit werden zu lassen. Aber keiner der aktuellen Ansätze kann den Programmierer völlig ersetzen.
Was Dein Beispiel betrifft, würde ich einfach DataSets/DataTables verwenden, und gar kein Objektmodell erstellen. Objektmodelle reagieren nämlich sehr anfällig auf Anforderungsänderungen. Da sind wir schon beim Punkt. Der eine hält jene Architektur für geeignet ein bestimmtes Problem zu lösen, der andere ebene eine andere Architektur.
Versuche so viele Patterns, Architektur- und Vorgehensmodelle wie möglich kennenzulerenen. Dann wirst Du für die zu lösenden Aufgaben meistens was passendes finden. Wenn was für ein bestimmtes Problem gut funktioniert hat, kapselst Du die Vorgehensweise am besten in einer unabhängigen Komponente und sparst bei den nächsten ähnlichen Projekten 2 Drittel der Zeit.
hier habe ich noch was gefunden: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032262940&EventCategory=3&culture=en-US&CountryCode=US
Hallo Alle,
ich befinde mich noch in einer Phase in dieser ich die Technologien
auslote die ich in Zukunft verwenden möchte. Dazu gehörte auch unbedingt
OOP. Schön langsam wird mir klar warum ich für mein Problem kein Buch
gefunden habe. Ich bin davon ausgegangen das OOP völlig etwas anderes
ist als das bisher gekannte. Auch das es ein völlig anders Design der App
voraussetzt und ebenso beim Datenbankmodel.
Das ist nicht so! Beim App-Design gelten weiterhin die gleichen Regeln.
Im Datenbankmodel selbstverständlich auch.
Herzlichen Dank an alle die für diese Erkenntnis beigetragen haben.
Zwei Themen habe ich noch vor mit: OR-Mapper oder reiner ADO.NET?
und Reporting.
Gruß Kostas
Original von Kostas
...OR-Mapper oder reiner ADO.NET?
Schau mal auf folgendes Event: http://persistenceday.dotnetpro.de
siehe Werbung links!
Hallo Quallo,
das habe ich natürlich schon längst gebucht.
Für mich sicherlich sehr interessant.
Ich werde dabei sein.
Danke, und Dir noch eine schöne Zeit.
Kostas