Member eines Objektes (aka Entität)

Ok, wir müssen tiefer einsteigen. Jetzt wird es aber theoretisch. Es gibt bestimmte Objekte, deren Eigenschaften über ein Schlüssel erreichbar sind. Diese Objekte nennen wir Entitäten (str, aber lass uns bei dieser Begrifffsdefinition bleiben).

Nehmen wir etwa eine person. Über die erhältst du Auskunft über die Schlüssel @"Name", @"Vorname" usw.

Es gibt auch andere Objekte. NSString-Instanzen etwa. Die sind keine Entitäten. Es gibt keinen Schlüssel für irgendwas. Es sind sozusagen "die Skalare der OO-Welt".

Jede Entität besteht im Wesentlichem aus solchen Skalaren (Die Entität person besteht aus etwa aus dem Skalar @"namen", welches ein NSString ist.), die wir etwa Atttribute nennen können und Beziehungen zu anderen Entitäten (Etwa Eltern, Kinder, Anschriften usw.), die wir Beziehungen nennen können.

So weit, so gut.

Jedes Attribut wird durch eine intrinsische (= gehörende) Instanz dargestellt, jede Beziehung durch eine (extrinsische) Referenz. Alles durch einen Member.

Langer Rede kurzer Sinn:
Wenn du eine Entität hast, die 60 bis 80 "Variablen" hat, dan machst du etwas falsch.

und nicht schlagen ...

gewalt ist nie eine Lösung!

Ich habe mir das mal angeschaut. Das ist in der tat völlig ausgeartet.

a) Es gibt noch andere Typen als NSString, etwa NSDate, NSNumber usw. Eine gute Typenwahl ist wie ein harmonisch gedeckter Tisch. Daran kannst du noch arbeiten.

b) Member-Orgien, wie *_muMod, *_muSt, *_muAkt, *_muX, *_muZu, *_muZumax,
*_klMod, *_klSt, *_klAkt, *_klX, *_klZu, *_klZumax,
*_inMod, *_inSt, *_inAkt, *_inX, *_inZu, *_inZumax,
*_chMod, *_chSt, *_chAkt, *_chX, *_chZu, *_chZumax,
*_ffMod, *_ffSt, *_ffAkt, *_ffX, *_ffZu, *_ffZumax,
*_geMod, *_geSt, *_geAkt, *_geX, *_geZu, *_geZumax,
*_koMod, *_koSt, *_koAkt, *_koX, *_koZu, *_koZumax,
*_kkMod, *_kkSt, *_kkAkt, *_kkX, *_kkZu, *_kkZumax,
*_gsMod, *_gsSt, *_gsAkt, *_gsX, *_gsZu, *_gsZumax,
*_leMod, *_leSt, *_leAkt, *_leX, *_leZu, *_leZumax,
*_auMod, *_auSt, *_auAkt, *_auX, *_auZu, *_auZumax,
*_aeMod, *_aeSt, *_aeAkt, *_aeX, *_aeZu, *_aeZumax,
*_keMod, *_keSt, *_keAkt, *_keX, *_keZu, *_keZumax,
*_mrMod, *_mrSt, *_mrAkt, *_mrX, *_mrZu, *_mrZumax,
*_iniMod, *_iniSt, *_iniAkt, *_iniX, *_iniZu, *_iniZumax,

lann kein Mensch warten. _aeAkt? Zieht sich da einer aus (Akt)? leZu? Könnte ein französischer Vorname sein. Immerhin: leX -- bei dir scheint das Recht zu herrschen.

Zusammengefasst: Eiin riesiger Gangbang mit französischen Mädchen, bei denen einer für das Recht sorgt. Das klingt jetzt aber nicht wie ein geordnetes Programm. (Wobei ich damit nichts gegen Gangbangs mit französischen Mädchen gesagt haben möchte!)

c) Ich gehöre eher zu denjenigen, die sich "totnormalisieren". Aber wie ich den Bezeichnungen entnehme, gibt es da zusammengehörige Gruppen. Die solltest du in zusammengehörigen Gruppen (aka Objekte) speichern.

Hey, nimm es nicht böse: Du stehst am Anfang, und wir haben alle schon Übleres verbrochen. Das gehört dazu. Aber da muss definitiv aufgeräumt werden.

Original von Breiti
die strings nehmen je einen wert auf für Mut klugheit charisma, fingerfertigkeit geschicklichkeit, und das je modifikation start aktuell aktuell2 zugekauft und dem maximalwert der zukäufe ... wie soll ich das nun gruppieren? oder besser womit

Mach einfach ein "Unterobjekt". Also erstelle Dir eine Klasse mit in der Art:
In Deiner Carakter-Klasse deklarierst Du dann einfach:
Und wenn Du dann alles richtig gemacht hast, kannst Du per Bindings über den keypath auf die einzelnen Werte zugreifen. :]

Michael

Michael hat dir ja schon gesagt, dass wenn du Gleiches mehrfach hast, es sich empfiehlt, dies zusammenzufassen.

Noch etwas:
Offenbar hast du dann ja eine ganze Latte von Instanzen der gleichen Klasse. Hier kann man dran denken, ob nicht eine weitere Collection sinnvoll ist. Also, du hängst dir etwa ein Dictionary herein, welches zu jeder Gruppe deine Instanzen hält. Du kannst das sogar ohne Key-Änderung machen, wenn du mein System hier:
macentwicklerwelt.net/index.ph…ding#KVC_und_NSDictionary
befolgst.

Alelrdings muss man bei dir auch an Folgendes denken:
Es gibt eigentlich gar keinen Grund, die Liste nicht als Array anzulegen. Dann hat zudem der Benutzer die Möglichkeit, selbst Gruppen anzulegen. Das wäre sicher nett. Du müsstest nur bei der Instantiierung des Instanzobjektes deine "vorgesetzten" Gruppen automatisch erzeugen, was sowohl im Code wie auch von einem Template-File aus kein problem ist. Auch kann man hier daran denken, dass man die in Defaults ablegt und dann in den Einstelungen, die Standardgruppen anlegt.
Möglicherweise musst du noch darauf achten, dass gewisse Gruppen gar nicht gelöscht werden dürfen, weil du sie essentiell benötigst. Das ist aber kein Problem. Melde dich dann einfach noch einmal.

darf ich um Beispiele für die Accessoren/init/dealloc bitten, hab hier schon wieder denkblockaden.

Es ist keine Entität, hat daher keine Accessoren. Einfach

int einInt = [NSNumber intValue];

und

NSNumber* number = [NSNumber numberWithInt:4];

In einem NSTableView kann ich dann die int genauso über Bindings abfragen wie ein NSString, oder?

Ja, das geht im Prinzip. Aber ich komme immer mehr dazu, alles in Objekten zu machen, also etwa NSNumber stat int. Nur for-Schleifen etc. mache ich noch über Skalare.

eine eigene klasse halte ich dafür für unnötig, geht das nicht evtl. auch mit struct oder union? wenn ja, wie? Auslesen, setzten mit " structname.muMax = wert "? Wie sieht es dann mit den settern/GetternInit/dealloc aus? je einen pro struktur?

Wenn du mit Strukturen all diese Fragen hast, warum nimmst du dann nicht eine Klasse?

WEnn du gleich dir eine eigene KLase machst, kannst du das alles übre Bindings machen und den Array-Controller die Verwaltung erledigen lassen.

zum einen weil das zusammenbleiben soll,

Das bleibt es bei einer Klasse doch auch!?

zum anderen weil ichs lernen will

Das ist ein gutes Argument. Du wirst aber vor allem lernen, dass du es nicht mehr verwenden willst.

Nein, das ist jetzt übertrieben. Aber für derlei Dinge eine Struktur zu nehmen in einer OO-Sprache, halte ich für "untertrieben".

Übrigens: so etwas wie Allokation gibt es bei Strukturren nicht. Auch nicht Accessoren.
Bist du dir immer noch sicher?

Ich meinte diese gruppen zur charakterklasse, wenn ich für die gruppen eine neue klasse anlege, muß ich ja im zweifelsfalle 2 klassen in ein neues projekt setzen, obwohl ich nur eine charakterklasse habe die angesprochen werden soll.

Du hast in einem Projekt gerne Dutzende von Klassen. Kein-KLassigkeit ist ein Zeichen von Güte, weil jede Klasse dann wartbarer bleibt. (Irgendwann wird es dann freilich schwachsinnig.) Du wirst im Laufe der Zeit noch bemerken, wie häufig du Spezialklassen von Cocoa untergeschoben bekommst, von denen du noch nie etwsa gehört hast.

war ich nie, war mehr ne frage ich will halt keine tausend accessoren und dennoch sauber programmieren

Wenig Accessorn _ist_ sauber programmiert. Das ist _kein_ Zielkonflikt.

Mach dir eine entsprechende Klasse und gut ist es. Das ist so richig und sauber!

Original von Breiti
ich will halt keine tausend accessoren und dennoch sauber programmieren

Gerade deshalb ist eine eigene Klasse gegenüber einer Struktur im Vorteil. Wenn Du hier statt einer Klasse eine Struktur nehmen würdest, würdest Du nicht einen Accessor einsparen.

Michael

hi

da das ja ofiziell ein "blöde-fragen-thread" ist getraue ich mich wieder einmal eine frage zu stellen

also folgendes:

ich habe folgenden code:


ich würde gerne auf die angegebene url auf das Feld "feld_test" ein wort senden. in meinemer späteren anwendung natürlich werte für mehrere felder...

nun habe ich bereits herausgefunden das ich das ganze irgend wie in ein NSData speichern muss und dieses nachher umwandeln...

für einige codeschnippsel wäre ich sehr dankbar...

viele grüsse

phil

ich hab jetzt mal ein bisschen drüber meditiert und versuche mal in worte zu fassen was mir im kopf rumfliegt. vielleicht habe ich ja das mit dem klassensystem noch nicht ganz verstanden. ich wollte eine komplette klasse schreiben ("charakter"), in der alles zusammen ist was zu einem charakter gehört, also diverse basiswerte, charakterzüge, herkunft, rasse etc. (alternativ: ich wollte ein auto mit allem drin, navi, lenkrad, rädern etc.). verstehe ich nun richtig das ich eigenschaften, wie charakter, basis, rasse etc (lenkrad, airbag, fahrersitz) in eigene klassen setzen soll um damit die klasse "charakter" (auto) nur zu nutzen um zu sagen das alle diese teile zusammen dann den charakter selbst darstellen (oder das auto) ?

Also mal abgesehen davon, dass jedes deiner Objekt ja in der Regel wieder Objekte enthält (das geht dann runter bis zu Cocoa-Klassen), sollst du nicht alles extern packen.

Du hattest wiederholende Muster. Dieses Muster solst du in eine eigene Klasse packen und in deiner Basisklasse nur wiederholen.

Ob du verschiedene Teile in eigene Klassen packst, ist Geschmacksfrage. Kurze Regeln:
- Kleiner und handlicher ist häufig besser: Mache Teile draus.
- Wenn es extern Sinn macht, mit Teilen zu arbeiten, dann mache Teile daraus.
- Klein-Klassigkeit ist häufig besser wartbar.

mir persönlich käme das ein wenig zweckentfremdet vor, da ich ja "charakter" (auto) als basis nehmen will um damit werte zusammen zu speichern (oder wohin zu fahren) und einige kleinere berechnungen zu erstellen.

Daran hindern dich ja Teile nicht.

wäre ich nun gott und würde "charaker" definieren, oder ggf umändern,(oder wäre ich der autobauer der sich ab und zu neue zulieferer sucht), verstände ich die aufteilung. ist es in etwa so gedacht gewesen, oder gibts da noch was an das ich gar nicht gedacht habe?

Es ist so gedacht gewesen, dass man Sich-Wiederholendes in eine eigene Einheit packt und dann nur noch die Einheit wiederholt, weil sich das leichter warten lässt.

btw kommt es mir nicht darauf an um jeden preis zeilen zu sparen (z.b. mit listen), sondern sauberen und vor allem richtigen code zu fabrizieren. hier lese ich dann "accessoren" für ..., das ist sauber und dann da ... wenig code/eigenschaften pro klasse ist gut. wie, genau, würdet ihr das denn anstellen?

Tendentiell ist kleiner sauberer, weil der Mensch mit Bleiwüsten Probleme hat.

Wir würden das aufteilen. Das hatten wir aber auch schon gesagt?

Du machst dir in der Klasse der einzellnen Einträge einen Member -(BOOL)isEditable.

Dann bindest du das ganze an im Table-View bei der Spalte mit mit Editbale-Binding.