Klasse mit Array aus einer andere Klasse und darauf zugreifen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Klasse mit Array aus einer andere Klasse und darauf zugreifen

    Hi,

    ich habe eine Klasse, die ein Array von einer 2. Klasse beinhaltet, die selbst wieder ein Array beinhaltet.
    Das ganze sieht ungefähr so aus:

    Klasse: Temperaturfuehler
    Property: Kennung: String
    Property: Temperatur: Double
    Klasse: Raum
    Property: Raumkennung: String
    Property: Fuehler: Array[Temperaturfuehler]
    Klasse: Haus
    Property: Besitzer: String
    Property: Raeume: Array[Raum]Soweit okay. Aus dieser Klasse erzeuge ich mir jetzt ein Objekt, und kann das Property Besitzer problemlos verwenden. Das Array Raeume ist erst mal leer.
    Jetzt soll ein Raum hinzugefügt werden. Also muss erst mal geprüft werden, ob dieser Raum bereits existiert.
    Das würde ich so machen:

    Quellcode

    1. var found = false
    2. for r in Haus.Raeume where r.Raumkennung == "Raum1" {
    3. let raum = r
    4. found = true
    5. }
    6. if !found {
    7. r = Raum(Raumkennung: "Raum1")
    8. Haus.Raeume.append(r)
    9. }
    10. // r ist jetzt das Object, welches im Array drin ist
    11. for t in r.Fuehler where t.Kennung == "12345678" {
    13. }
    Alles anzeigen
    Nun kann ich aber schon auf r nicht wirklich zugreifen, als nehme ich mal an, dass es so nicht geht.
    Wie kann man sowas realisieren?
    Bin noch neu mit Swift, daher die blöde Frage ;) In meiner alten Programmiersprache konnte ich mir einfach einer Referenz auf eine Klasse anlegen und dann den Pointer eines bestehenden, gleichen Objekts zuweisen um damit weiter zu arbeiten.

    Gruß Dieter

  • Gibt es denn in der Swift SDL (also ohne zusätzliche Frameworks) auch einen 'Set' Collection Type, oder haben sie den aus Geschwindigkeitsgründen (Existenz prüfen kostet ja Zeit) weggelassen?
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Captnemo schrieb:


    Ist das denn so eine gängige Vorgehensweise? In meiner bisherigen Sprache habe ich einfach die Klasse mit entsprechenden Funktionen ausgestattet z.B. Raum.IndexOfRaumkennung("blabla").
    "let" ist doch für konstanten. Außerdem ist das in einem anderen scope...

    ich würde das mit einer eigenen methode a la "roomNamed:createIfNotAvailable:" erstellen (ist jetzt obj-c syntax).

  • Captnemo schrieb:

    Ist das denn so eine gängige Vorgehensweise? In meiner bisherigen Sprache habe ich einfach die Klasse mit entsprechenden Funktionen ausgestattet z.B. Raum.IndexOfRaumkennung("blabla").
    Scopes sind gängige Vorgehensweise und meist durch die Programmiersprache vorgegeben. ;)

    Was ist denn Deine 'bisherige' Sprache?
    Raum.IndexOfRaumkennung("blabla") sieht irgendwie schräg aus.
    Wieso verwaltet der Raum seine und andere Kennungen? Warum liefert das einen Index anstelle der Referenz?
    hausInstanz.raum(kennung: "blabla") fühlt sich richtiger an.

    Dank Polymorphie geht zusätzlich noch hausInstanz.raum(index: 0), halte ich aber für sinnlos.
    Schließlich liefert hausInstanz.Raeume[0] dasselbe Ergebnis.

    Im Übrigen würde ich die Instanzvariablen niemals direkt verändern.
    Also statt Haus.Raeume.append(r) lieber ein selbst geschriebenes hausInstanz.addRoom(r) und die Räume Property als Readonly deklarieren.
    Mutable Instanzvariablen können auch in Swift zu unerwünschten Seiteneffekten führen.
    Jetzt muss man natürlich wissen, dass ein Swift Array eine Struktur ist und dementsprechend ein bisschen anders auf Methodenaufrufe reagiert als ein NSArray.
    Ob man aber drei Wochen später immer noch weiß, welches Array man da jetzt genommen hat...

    Davon abgesehen würde ich hier nicht einmal Objekte nehmen sondern ausschließlich mit Strukturen arbeiten.
    Aktuell tun Deine Objekte ja nichts weiter als Daten verwalten. Dafür sind Strukturen in Swift besser geeignet.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Captnemo schrieb:

    Ist das denn so eine gängige Vorgehensweise? In meiner bisherigen Sprache habe ich einfach die Klasse mit entsprechenden Funktionen ausgestattet z.B. Raum.IndexOfRaumkennung("blabla").
    Scopes sind gängige Vorgehensweise und meist durch die Programmiersprache vorgegeben. ;)
    Was ist denn Deine 'bisherige' Sprache?
    Raum.IndexOfRaumkennung("blabla") sieht irgendwie schräg aus.
    Wieso verwaltet der Raum seine und andere Kennungen? Warum liefert das einen Index anstelle der Referenz?
    hausInstanz.raum(kennung: "blabla") fühlt sich richtiger an.

    Dank Polymorphie geht zusätzlich noch hausInstanz.raum(index: 0), halte ich aber für sinnlos.
    Schließlich liefert hausInstanz.Raeume[0] dasselbe Ergebnis.

    Im Übrigen würde ich die Instanzvariablen niemals direkt verändern.
    Also statt Haus.Raeume.append(r) lieber ein selbst geschriebenes hausInstanz.addRoom(r) und die Räume Property als Readonly deklarieren.
    Mutable Instanzvariablen können auch in Swift zu unerwünschten Seiteneffekten führen.
    Jetzt muss man natürlich wissen, dass ein Swift Array eine Struktur ist und dementsprechend ein bisschen anders auf Methodenaufrufe reagiert als ein NSArray.
    Ob man aber drei Wochen später immer noch weiß, welches Array man da jetzt genommen hat...

    Davon abgesehen würde ich hier nicht einmal Objekte nehmen sondern ausschließlich mit Strukturen arbeiten.
    Aktuell tun Deine Objekte ja nichts weiter als Daten verwalten. Dafür sind Strukturen in Swift besser geeignet.
    Hi,

    also, bisherige Programmiersprache: Pascal, oder genauer Delphi

    Ja, natürlich Raum.IndexOfRaumkennung() war natürlich Quatsch. Dort sollte eigentlich Raeume.IndexOfRaumkennung() gemeint sein.
    Referenz schaut natürlich noch etwas "lesbarer" aus. Muss nur erst mal lernen wie ich das jetzt wieder mache.

    Sicherlich ist diese Art der Klassennutzung noch etwas unbeholfen, aber irgendwo muss man ja anfangen. Und im meinem Statium bin ich schon froh, dass es überhaupt so halbwegs klappt. Sicherlich spielen da meine Angewohnheiten von Delphi auch eine große Rolle. Und alte Schuhe abzulegen ist nicht immer so einfach. Dazu kommt noch, dass man im Internet auf der Suche nach Tutorials, Beispielen und Möglichkeiten auf die unterschiedlichsten Meinungen und Verfahren stößt, und immer wieder Objectiv-C (was ich logischerweise auch nicht so gut behersche) Beispiele findet, die einen dann zusätzlich Verwirren.

    Desweiteren ist mir der Unterschied zwischen Klasse und Struktur bzw. der Vor- und Nachteil untereinander noch nicht ganz bewußt. Nach dem was ich bisher gelesen habe, hat eine Klasse mehr programmiertechnische Möglichkeiten. So in etwas wie unter Delphi Kasse und Record.

    Ich kämpfe halt an allen Ecken (ist halt alles neu für mich).

  • Captnemo schrieb:


    Desweiteren ist mir der Unterschied zwischen Klasse und Struktur bzw. der Vor- und Nachteil untereinander noch nicht ganz bewußt. Nach dem was ich bisher gelesen habe, hat eine Klasse mehr programmiertechnische Möglichkeiten.
    In Swift sieht das so aus:

    Klasse: Der Speicher wird auf dem Heap alloziert.
    struct: Der Speicher wird auf dem Stack alloziert.

    Bei der Übergabe als Funktionsparameter wird eine Klasse als Referenz zum Original übergeben, structs werden kopiert (copy on write).

    Vom Funktionsumfang haben sich unter Swift Klassen und structs ('programmiertechnische Möglichkeiten') angenähert. Structs können da im Gegensatz zur C-Familie auch Methoden haben, nur Vererbung geht bei structs nicht.

    structs nimmt man für Werte, Klassen für Objekte...

    Mhhh... Ich befürchte, das verwirrt mehr als es hilft. Vielleicht kann es jemand besser erklären. sorry...

  • gritsch schrieb:

    tsunamix schrieb:

    Structs können da im Gegensatz zur C-Familie auch Methoden haben, nur Vererbung geht bei structs nicht.
    Naja, in C++ (was ja auch zur C-Familie gehört) können structs sehr wohl methoden besitzen und unterstützen auch vererbung - mit swift hat das natürlich nichts zu tun, wollte es nur schnell anmerken.
    OK. Danke für die Klarstellung. C++ ist für mich ein Buch mit sieben Siegeln. Bin dann wohl von C/Objective-C einen Schritt zu weit gegangen...

  • tsunamix schrieb:

    Klasse: Der Speicher wird auf dem Heap alloziert.
    struct: Der Speicher wird auf dem Stack alloziert.
    Das ist generell so nicht richtig: Ein optionales Struct liegt auch im Heap.

    Wichtiger ist die Zuweisungsregel. Structs sind Werttypen, deren Inhalt bei einer Zuweisung kopiert wird. Im Gegensatz dazu sind Swift-Klassen Referenztypen, wo bei einer Variablenzuweisung lediglich Referenzen verbogen.

    Quellcode

    1. import Foundation
    2. var a = [ 1 ]
    3. var b = a
    4. let n = NSMutableArray(object: 1)
    5. let m = n
    6. b.append(2)
    7. m.addObject(2)
    8. print(a)
    9. print(n)
    Preisfrage: Welche Werte enthalten a und n?
    „Meine Komplikation hatte eine Komplikation.“

  • Hallo,

    eine Andere Frage:
    Wie Speicherst denn du diese Klasse bzw. wird sie wieder geladen?

    beim mir Wird nur immer die erste Ebene gespeichert

    verwende dazu NSKeyedArchiver

    Danke für Infos

    Mario
    _________________________________________________
    Tue was du willst, solange du niemanden damit schadest,
    denn die Liebe ist das wahre Gesetz

  • tsunamix schrieb:

    Mhhh... Ich befürchte, das verwirrt mehr als es hilft. Vielleicht kann es jemand besser erklären. sorry...
    Nein, im Gegenteil. Eine kurze und knappe Erklärung, die erst mal eine gute Definition darstellt.

    Wenn man nun also Klassen für Objekte verwenden soll, aber die Objekte dann natürlich Werte beinhalten?

    Nehmen wir mal das berühmte Beispiel: das Auto.

    Jetzt könnte ich ein Auto eine Klasse definieren, da ich ja vor habe der Klasse Funktionen wie beschleunigen, bremsen usw. zu geben.
    Darüber hinaus hat natürlich ein Auto auch Werte, wie Anzahl der Türen, PS, usw. Das wären ja Werte. Dafür sollte man jetzt wieder ein Struct nehmen?

    Wann ist denn eine Klasse sinnvoller und wann ein Struct?