Original von donadm

2- 7 I6 --- PPM *[700001/789676]+ Designation of the star
10-18 A9 --- DM *Durchmusterung, BD or CD
20-23 F4.1 mag Mag *Magnitude, Visual if Flag5 is 'V'
25-26 A2 --- Sp *Spectral type
28-29 I2 h RAh Right Ascension for the Equinox=J2000.0 5
31-32 I2 min RAm Right Ascension J2000 (minutes)
34-39 F6.3 s RAs Right Ascension J2000 (seconds)
42 A1 --- DE- Declination J2000 (sign)
43-44 I2 deg DEd Declination for the equinox and epoch
...

hier stehen Byte-Bereiche, was für welche Daten reserviert ist.

* Da es hier um grosse Datenmengen geht (die zusäzlich zur Laufzeit des Programms "fliessen"
müssen), müsste ich mir Strategien zur Verarbeitung überlegen? Evtl. könnte man das Ganze
in eine Datenbank importieren, doch hier sehe ich die Gefahr, das das "Lesen" zu langsam geht?

Original von donadm
Frage, arbeitet ihr auch nach dem MCV(Model-Controller-View) Paradigma?
Oder ist das für den anfang nur recht hilfreich?

Original von gritsch
ich würd dir raten die finger erstmal vo fortran zu lassen weil man muss ja nicht alles auf einmal lernen.
...
das ist am eifnachsten: datei mit fopen öffnen, fscanf so lange durchlaufen lassen bis er nix mehr fidnet in der datei. und mit fclose die datei schließen.

Original von donadm

Dadurch wäre auch garantiert, daß die Formate exakt genau so interpretiert würden wie die Datenquelle das vorsieht.

Kurze Gegenfrage, wie sieht die Datenquelle das denn vor?

Wenn ich ehrlich bin verstehe ich es eh nicht so, ich könnte mir nur abstrakt vorstellen,
das zB beim Ersten das "I6" bedeutet, Integer 6Byte oder 6Zeichen oderso?
Beim Zweiten"A6" dann Ascii 6 Zeichen, und das "F4.1" evtl Float.

a) Manuell: Ändert sich etwas im Model, so muss dies der Controller abholen und im View setzen. Das bedeutet bei größeren Applikationen viel Arbeit und ist schlecht zu warten.

b) Data-Sources: Du implementierst ein Objekt, welches NAchrichten vom View bekommt, wenn eine Änderung notwednig ist.

c) Bindings: Du verwendest die Standard-Bindings-Controller von Cocoa.

Objektarten
In Objective-C haben wir es also mit Objekten zu tun. Aber das kann man natürlich
auch detaillierter betrachten.

Klassen- und Instanzobjekte
Bisher war immer von Objekten die Rede. Dabei unterscheidet Objective-C zwischen
zwei Typen von Objekten: Die üblichen Objekte sind Instanzobjekte – oder kurz: Ins-
tanzen. Sie sind Objekte im klassischen Sinne mit Daten und Operationen, die über
Methoden ausgeführt werden.
Sie haben bereits gelernt, dass jedes Objekt eine Klasse hat, die gewissermaßen den
Typ des Objektes angibt. In Objective-C ist diese Klasse jedoch wiederum ein Objekt,
ein Klassenobjekt. Solche Klassenobjekte besitzen keine Daten, sondern nur Operati-
onen. Sie werden auch nicht im Programm von Ihnen erzeugt, sondern sind »einfach
da«. Jedes genau einmal. Diese Eigenarten kann man zuweilen nützlich einsetzen. Für
Sie reicht es an dieser Stelle aus, den praktischen Nutzen zu kennen:
< Klassenobjekte erzeugen die Instanzobjekte. Das wird etwas später erläutert.
85
kaPitel 3c und oBjective-c
< Klassenobjekte stehen stellvertretend für ein im System nur einmal existierendes
Ding.
So steht das Klassenobjekt NSApplication für unser Programm. In unserem Pro-
gramm gibt es das Programm ja nur einmal. NSUserDefaults steht für unsere Pro-
grammeinstellungen, die es pro Programm ebenfalls nur einmal gibt.
Man nennt solch einmalige Objekte Singletons. Wenn man eine Eigenschaft oder
eine Fähigkeit eines Objektes benutzen will, so muss man stets gerade das entspre-
chende Objekt zur Hand haben. Es ist nicht immer leicht, es zu finden, wenn es von
der gleichen Klasse mehrere Objekte gibt. Da jedoch Singletons wie Klassenobjekte
stets nur einmal existieren, kann es keine Verwechslung geben. Man kann überall im
Programm einfach das Klassenobjekt benutzen. Die Anwendung ist denkbar einfach:
Statt des Namens einer Variablen schreibt man einfach den Namen der Klasse hin.
Will man etwa wissen, in welches unserer vielleicht zahlreichen Fenster der Nutzer
schreiben kann, so schreibt man einfach [NSApplication keyWindow]. Sie lösen damit
das Konzept der globalen Variablen ab, die für ihre Fehleranfälligkeit berühmt und
berüchtigt sind.
Entitäten und Container
Die Instanzobjekte kann man wiederum in zwei Arten unterteilen: Entitäten und
Container. Beide bestehen aus – da sie Instanzobjekte sind – Daten und Operationen.
Der Unterschied liegt in der Organisation der Daten. Entitäten haben Eigenschaften,
denen wir Namen geben. Im vorangegangenen Beispiel hat ein Instrument die Ei-
genschaften Art, Preis und Alter. Diese Beziehung zwischen Eigenschaft und ihrem
Namen ist übrigens typisch für Ihre Programmierarbeit. Sie erstellen fast immer
Entitäten.
Dies ist aber nicht bei allen Objekten so. Manche Objekte dienen uns nur als Ablage
für irgendwelchen Daten-Krimskrams. Sie haben doch sicher auch so eine Küchen-
schublade, in der sich alles Mögliche tummelt: Container. Man kann da keine Eigen-
schaften benennen. Wichtigstes Beispiel sind Objekte der Klasse NSString. Ein String
ist ein unformatierter Text, ein Zeichenwurm. Da gibt es keine Eigenschaften. Wel-
che auch? Daneben existieren »Sporttaschen«. Sie können einen ganzen Haufen von
Objekten sammeln. Der wichtigste Fall ist hier NSArray. Hierbei werden einfach alle
ÜAuFGepAssT
In diesem Buch wird häufig von Objekten die Rede sein. Damit sind hier stets die
Instanzobjekte gemeint. Dieser in Objective-C eigentlich etwas unscharfe Begriff
hat sich so eingebürgert. Wenn es wie hier gerade darauf ankommt, wird dies na-
türlich klargestellt.
86
SmartBookS oBjective-c und cocoa – Programmieren unter aPPle mac oS X
gesammelten Objekte durchnummeriert. So sieht die Liste der wichtigsten Klassen
aus, mit denen Sie es früher oder später zu tun bekommen:
Klasse Beschreibung Beispiel
NSString Einfacher TextNamen, Buchtitel, Erläuterungen
NSValue Jede Art von numerischen WertenBereiche (Von-Bis),
Koordinatenangaben (x,y)
NSNumber ZahlenGanze Zahlen, gebrochene Zahlen
NSSet Unsortierte Sammlung von einmaligen ObjektenListe
der lieferbaren Produkte (Jedes Produkt wird nur ein-
mal aufgeführt!)
NSCountedSet Unsortierte Sammlung von Objekten, Doppel er-
laubtLagerbestand (Jedes Produkt kann mehrfach auf
Lager liegen!)
NSArray Nummerierte Sammlung von ObjektenNummerierte
Klassenliste
NSDictionary Sammlung von Objekten, bezogen auf ein anderes
Objekt.Telefonlisten (Nummern bezogen auf Namen.
Der Name darf immer nur einmal verwendet werden,
die Telefonnummer mehrfach.)
Diese Container werden im Kapitel – na, raten Sie mal – Container näher bespre-
chen. Sie selbst erstellen so gut wie nie solche Klassen, sondern benutzen sie einfach
in Ihrem Programm.
87
kaPitel 3c und oBjective-c
So kompliziert sind sie gar nicht, die verschiedenen Arten von Objekten.
»Swinger-Club« für Objekte – Attribute und Beziehungen
Wie dargestellt besitzen Entitäten Eigenschaften. In unserem Beispiel waren die ge-
nannten Eigenschaften Art, Alter und Preis. Diese Eigenschaften beschreiben das In-
strument. Man nennt sie daher Attribute. Daneben können Eigenschaften aber auch
in Beziehungen zu anderen Entitäten bestehen. Nehmen wir an, dass wir nicht nur
jede Menge Instrumente in unserem Programm haben, sondern auch Musikanten.
Ein Musikant wäre kein Musikant, wenn er nicht ein Instrument spielen könnte. Also
hat er die Eigenschaft KannInstrumentXSpielen. Diese Eigenschaft verweist von einer
Entität (Musikant) auf eine andere Entität (Instrument). Man nennt dies eine Bezie-
hung oder Relation.
Die Beziehungen kann man übrigens wiederum nach ihrer Komplexität unterteilen:
Einfachstes Beispiel: Jede Ehefrau hat genau einen Mann. Jeder Mann hat genau eine
Frau. Diese Beziehung nennt man 1-zu-1-Beziehung (1:1-Beziehung).
ÜGruNDLAGeN
Es gibt vereinfacht einen (allerdings nicht zwingenden) Zusammenhang zwischen
Attributen und Relationen einerseits und Entitäten und Containern andererseits:
Attribute sind der Verweis einer Entität auf einen Container, etwa Musikant (Enti-
tät) und sein Name (Container NSString). Relationen sind Verweise einer Entität
(Musikant) auf andere Entitäten (Instrument).
88
SmartBookS oBjective-c und cocoa – Programmieren unter aPPle mac oS X
Häufigster Fall in der Programmierung ist jedoch, dass eine Entität sich auf mehrere
andere Entitäten bezieht. Beschreiten wir jetzt doch den Weg nicht-westlicher Gesell-
schaften und schauen uns die Polygamie an: Dort kann eine Frau mehrere Ehemänner
haben. Man bezeichnet eine solche Beziehung auch als 1-zu-n-Beziehung (1:n-Be-
ziehung). Schließlich können wir es ganz kompliziert machen. Ohne einen Rest sitt-
lichen Anstands zu verlieren, erkennen wir die »Gruppenehe« an. Bei dieser kann ein
Mann mehrere Ehefrauen haben (1:n-Beziehung) und eine Ehefrau mehrere Männer
(1:m-Beziehung). Man nennt dies eine n-zu-m-Beziehung (n:m-Beziehung).
In Programmen geht es unsittlich zu.
Diese Beziehungsarten sind aus der Datenbankentwicklung entstanden. Und wir dür-
fen bei der objekt-orientierten Anwendungsentwicklung etwas vereinfachen: Häufig
speichert man eine Beziehung nur in eine Richtung, nehmen wir an von Entität Ehe-
frau zur Entität Ehemann. Damit kann man zusammenfassen:
Vom Standpunkt der Frau aus gibt es nur zwei Beziehungsarten.
Es gibt also nur noch die Fälle, in denen entweder eine Frau auf einen Mann verweist
(Einehe) oder eine Frau auf mehrere Männer verweist (Vielehe und Gruppenehe).
Dementsprechend nennt man die einfache Beziehung Master-Detail-Relationship,
die mehrfache Beziehung To-Many-Relationship. Eine Gruppenehe unterscheidet
sich von der Vielehe lediglich dadurch, dass mehrere Pfeile auf einen Mann zeigen.
Dies ist jedoch für die Frau, deren Klasse wir ja programmieren, unbeachtlich.
kaPitel 3c und oBjective-c
Wenn wir jedoch genau die umgekehrte Blickrichtung betrachten, so stellt sich für
den Mann, dessen Klasse wir auch programmieren müssen genau das umgekehrte
Bild dar:
Bei der Rückbeziehung Mann zu Frau stellt sich die Lage anders dar.
Die Quintessenz ist also, dass 1:1-, 1:n- und n:m-Beziehungen je vom Standpunkt aus
Master-Detail- oder To-Many-Relationships sind, da die Beziehungen ja auch Eigen-
schaften sind. Wir haben es also nur mit diesen Beziehungstypen zu tun.
Auch Xcode kann derlei Beziehungsmuster, Entity-Relationship-Model (ERM) ge-
nannt, grafisch darstellen:
Und wenn wir uns von Xcode auch noch die Rückverweise anzeigen lassen, dann
wird die Sache klar:
Die einfache Pfeilspitze zeigt, dass es
sich um eine Master-Detail-Beziehung
handelt.
Die doppelte Pfeilspitze zeigt die To-
Many-Beziehung an.

Original von donadm
wie ist eigentlich die Lebensdauer der Objekte? Also wenn ich sie nicht mehr haben will?
Was mach ich dann?

Original von donadm
Aber neben all dem Theoretischen, jetzt weiss ich absolut nicht, was ich machen soll?