Klassendesign
-
Ich bin dabei, eine Klasse zu schreiben, in der sich eine Menge Elementvariablen
angesammelt haben. Das Programm, in dem sie eingesetzt werden soll
dient zur Projektorganisation, diese Klasse soll sämtliche Daten eines
Projekts (Startdatum, Kurzbeschreibung, beteiligte Mitarbeiter, Status...) speichern
und verwalten: Wenn der Status den und den Wert hat, darf sich ein anderer
nicht ändern.....
Von der Seite also recht trivial. Es sind nur gut 20 Elemtevariablen,
mit den Lese- und Änderungsmethoden sammelt sich da einiges an.
Gibt es zB rein formale Möglichkeiten, so etwas zu organisieren, ist das
ganz normal, oder habt ihr andere Tipps ??
(*schauder* vor neuer Rechtschreibung)
-
Das Programm, in dem sie eingesetzt werden soll
dient zur Projektorganisation, diese Klasse soll sämtliche Daten eines
Projekts (Startdatum, Kurzbeschreibung, beteiligte Mitarbeiter, Status...) speichern
und verwalten:Hört sich für mich nach etwas viel für eine Klasse an. Außerdem erscheint mir das auch ziemlich datenzentriert. Eine Klasse sollte aber nicht primär ein Datenspeicher sein.
-
Was benutzt man denn dann, wenn man primär viele Daten kapseln will?
-
struct?
-
structs sind auch Klassen.
-
structs sind auch Klassen.
Sehe ich nicht so. Zwar kann eine struct genau das gleiche sein wie eine Klasse die erwartete Sematik ist aber eine völlig andere. structs symbolisieren simple Datenspeicher ohne viel Leben. Vorallem aber Konzepte bei denen es nicht um Kapselung geht. Klassen bzw. deren Objekte stellen selbstverantwortliche Einheiten dar, die sich neben den Daten vorallem durch ihr verhalten auszeichnen. Auf Sprachebene mögen die beiden gleich sein. In den Erwartung die man an die beiden stellt, unterscheiden sich struct und class aber gewaltig.
Zumindest habe ich das bisher nahezu überall so gelesen.
[ Dieser Beitrag wurde am 26.11.2002 um 00:58 Uhr von HumeSikkins editiert. ]
-
jepp!
-
Euren Antworten entnehme ich, dass es hier keine anderen Möglichkeiten
gibt.Was das class/struct-Problem angeht, nur um euch zu beruhigen.
Die Klasse macht noch ein paar andere Sachen, als nur Daten zu speichern.
Insofern kann man sie als "echte" Klasse ansehen, auch wenn die Einwende
dagegen natürlcih nicht unbegründet sind.
Hier einen anderen Weg einzuschlagen ist mir aber sowieso nicht möglich,
die Vorgabe "bau das in eine Klasse" ist fest gesetzt und läst sich
jetzt nicht mehr ohne weiteres umbauen.
-
Original erstellt von Taurin:
"bau das in eine Klasse"echt?
blöde vorgabe!das sollten n paar Klassen sein...
-
Original erstellt von Taurin:
Hier einen anderen Weg einzuschlagen ist mir aber sowieso nicht möglich,
die Vorgabe "bau das in eine Klasse" ist fest gesetzt und läst sich
jetzt nicht mehr ohne weiteres umbauen.Oh doch! Du kannst z.B. Klassen innerhalb von Klassen anlegen, also lokale Klassen. Sowohl public als auch private. Die äußere Klasse entspricht dann schon eher einem Namespace und weniger einer Klasse, aber egal. Du erfüllst auf jeden Fall die Bedingung, aber hast trotzdem eine feinere Struktur.
-
Hm, klingt für mich alles einwenig spanisch.
Macht eigentlich keinen Sinn, für viele daten eine Klasse zu basteln, oder
ein Struct. Sagt dir etwas der Begriff Normalisierung etwas ?
Du solltest mal versuchen die Daten sinnvoll zu gruppieren, und sie
dann so einzelnd in Gruppen zu kapseln.Devil
-
Original erstellt von devil81:
**Hm, klingt für mich alles einwenig spanisch.
Macht eigentlich keinen Sinn, für viele daten eine Klasse zu basteln, oder
ein Struct. Sagt dir etwas der Begriff Normalisierung etwas ?
**normalisierung gibts in 100 kontexten. nur in einem nicht, dem klassendesign.
dein beitrag wurde hiermit als ungültig abgelehnt.
-
Original erstellt von volkard:
**
normalisierung gibts in 100 kontexten. nur in einem nicht, dem klassendesign.
dein beitrag wurde hiermit als ungültig abgelehnt.**Wennd du das sagst muss das wohl stimmen
Devil
-
Wennd du das sagst muss das wohl stimmen
Nö. Stimmt nicht. Gestern 13:30h-15:00h Softwarekonstruktion bei Professor E.Horn. Thema von der Terminimodellierung zur logischen OO-Modellierung. Unterthemen: komposite Klassen, auflösen von Relationen und prozedurale Abstraktion.
Und was sagt unsere Professorin? "Kennen Sie die sieben Normalisierungsregeln des Datenbankdesigns? Ja. Gut. Die brauchen sie hier. 1. blabla, 2. blublu, 3. blabla." Gut, wir brauchten nur drei (oder ich kann nicht zählen), aber das beweist doch, dass es sowas wie Normalisierung auch im Klassendesign gibt.Ob das nun sinnvoll ist oder nicht, sei mal dahingestellt. Ich fand's auf jeden Fall sehr aufgedrückt.
-
Auf ähnliche Ideen bin ich inzwischen auch gekommen
Das ganze sieht immer noch ein bischen lang aus, aber hauptsächlich
wegen der Sprache: Ich hab immer das Gefühl, in delphi sieht alles
längern und massiver aus. Muss an den begin/end's liegen anstatt
der schmucken, geschweiften Klammern und der fehlenden Möglichkeit,
Funktionen im Declarationsteil inline zu implementieren.
Ich werd mal schauen, was sich machen lässt.
Danke.[ Dieser Beitrag wurde am 27.11.2002 um 13:59 Uhr von Taurin editiert. ]