externe Variablen/Typen

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

  • externe Variablen/Typen

    Hey, beim Einloggen in meine App gibt man seinen Namen, Geburtstag and und bekommt eine ID zugewiesen.
    Jetzt habe ich eine Klasse User erstellt, mit den Eigenschaften und auf den User muss ich in allen Klassen drauf zugreifen können.
    Ist es besser, wenn ich die Variable User als globale Variable setzte (extern user *theUser) oder soll ich es in sharedDefaults speichern?
    Was ist "professioneller"? Oder gibt es andere/bessere Möglichkeiten zum Speichern des Users?
    Gruß Speedy
  • Prinzipiell machen beide das gleiche. Mit einer globalen Variable hast du weniger Tipparbeit. Mit einem Singleton erfüllst du die OOP Prinzipien.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von 99s99m ()

  • markusschalk schrieb:

    Prinzipiell machen beide das gleiche. Mit einer globalen Variable hast du weniger Tipparbeit. Mit einem Singleton erfüllst du die OO Prinzipien.


    Steht OO dabei für "Ohne Objekte" oder was?

    @TO Was spricht dagegen den User einfach jedem ViewController zu geben der ihn braucht? DAS ist dann OOP.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:


    @TO Was spricht dagegen den User einfach jedem ViewController zu geben der ihn braucht? DAS ist dann OOP.

    Dagegen spricht, dass die ViewController dann für andere Projekte nicht mehr zu gebrauchen sind, da sie direkt vom User Objekt abhängen.
    Sinnvoller wäre es, ihnen eine Datasource beizupulen, welche die benötigten Daten anfragt. Das User Objekt erfüllt dann einfach dieses Datasourceprotokoll und liefert die gewünschten Daten. ;)

    Wobei 'jedem ViewController eine Referenz übergeben' deutlich mehr OOP ist als selbst gefrickelte Singletons oder sharedInstances wie die User Defaults.
    Andererseits kann man durchaus argumentieren, dass besagte Userdaten zu den Benutzereinstellungen gehören und in die User Defaults geschrieben werden sollten.
    «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:


    Wobei 'jedem ViewController eine Referenz übergeben' deutlich mehr OOP ist als selbst gefrickelte Singletons oder sharedInstances wie die User Defaults.
    Andererseits kann man durchaus argumentieren, dass besagte Userdaten zu den Benutzereinstellungen gehören und in die User Defaults geschrieben werden sollten.


    Ja und am besten noch die Strings direkt in Klartext :)

    Wenn wir es mal ganz genau machen wollen (Und DU hast mit dem Erbsenzählen angefangen ;) ), dann gehört sowas in die Keychain.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    markusschalk schrieb:

    Prinzipiell machen beide das gleiche. Mit einer globalen Variable hast du weniger Tipparbeit. Mit einem Singleton erfüllst du die OO Prinzipien.


    Steht OO dabei für "Ohne Objekte" oder was?

    @TO Was spricht dagegen den User einfach jedem ViewController zu geben der ihn braucht? DAS ist dann OOP.

    Gruß

    Claus


    Ja, hab das P vergessen.
  • markusschalk schrieb:

    Thallius schrieb:

    markusschalk schrieb:

    Prinzipiell machen beide das gleiche. Mit einer globalen Variable hast du weniger Tipparbeit. Mit einem Singleton erfüllst du die OO Prinzipien.
    Steht OO dabei für "Ohne Objekte" oder was?
    Ja, hab das P vergessen.

    Also "Ohne Objekte Pfusch"?
    «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
  • Nö, eigentlich nicht: Benutze doch (wie Marco schrieb) ein zentrales Objekt zum Verwalten der Benutzerinformationen ... und wenn es aus Bequemlichkeit zunächst nur der AppDelegate ist. Implementiere dort ein eigenes Protokoll, welches die Benutzerinfos liefert und gib dieses Objekt Deinen Controllern als Datasource mit.

    So haben die VCs keinen spezifischen oder gar redundanten Code, und wie besagtes Objekt dann diese Infos speichert, ist seine eigene Sache, da können es auch die UserDefaults, die Key-Chain oder eine Kombination sein.

    Das wäre m. E. ein "echter" OOP-Ansatz ... was nicht heißt, dass ich diesen Weg immer gehe: Manchmal gewinnen aus Bequemlichkeit Properties des AppDelegates. Shame on me :)

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • SpeedyBrainy schrieb:

    Was ist mit Datensource gemeint?


    Eine Datasource ist ein Objekt, das anderen Objekten auf geordnete Weise Daten liefert.

    Aber meine Meinung: Vergiss' das. Keine Globals, kein App Delegate, keine Singletons, kein zentrales Verwaltungsobjekt, nichts in die Richtung. Dein Problem ist an einer ganz anderen Stelle:

    SpeedyBrainy schrieb:

    mit den Eigenschaften und auf den User muss ich in allen Klassen drauf zugreifen können


    Das ist das Problem: Nein, Du musst nicht aus allen Klassen auf etwas zugreifen können - oder falls das so ist, stimmt mit dem Design etwas nicht. Jedes Objekt darf nur die Teile seiner Umgebung kennen, die es wirklich braucht. Die Abhängigkeiten werden immer aktiv von draußen reingegeben (im Konstruktor, über Properties, über Delegates oder sonstwie). Wenn man denkt, dass das zu aufwändig und zu viel Tipparbeit ist, sollte man sich Gedanken darüber machen, warum eigentlich die Objekte so viel voneinander wissen müssen und wie man das verschlanken kann. Das ist lose Kopplung. Das Gegenteil davon heißt Murks.
    Multigrad - 360°-Produktfotografie für den Mac
  • mattik schrieb:

    Das ist das Problem: Nein, Du musst nicht aus allen Klassen auf etwas zugreifen können - oder falls das so ist, stimmt mit dem Design etwas nicht. Jedes Objekt darf nur die Teile seiner Umgebung kennen, die es wirklich braucht. Die Abhängigkeiten werden immer aktiv von draußen reingegeben (im Konstruktor, über Properties, über Delegates oder sonstwie). Wenn man denkt, dass das zu aufwändig und zu viel Tipparbeit ist, sollte man sich Gedanken darüber machen, warum eigentlich die Objekte so viel voneinander wissen müssen und wie man das verschlanken kann. Das ist lose Kopplung. Das Gegenteil davon heißt Murks.

    Kurz nachgefragt. Grundsätzlich bin ich ja deiner Meinung. Aber wie wäre das in folgender Situation:
    1. iPad. Auf jedem View habe ich oben rechts, den Namen der eingeloggten Person stehen und unter Umständen noch irgendeine Sessionabhängige Information.
    2. Ich habe eine Sessionverwaltung.
    Nun kann ich die Logdaten direkt im SessionModel speichern und von dort aus abrufen oder
    Ich speicher die Logdaten in ein eigenes LogdatenModel.

    Aber egal, was ich von beiden mache, ich muss von jedem Viewcontroller auf diese Daten zugreifen können.

    Wie würdest Du sowas lösen? Tatsächlich immer übergeben?
    Und ist eine Kopplung loser oder enger, wenn ich verpflichtet bin, die Daten der Klasse immer zu übergeben?

    nebenbei und unabhängig von dem oben genannten: Das Gegenteil von loser Kopplung ist die enge Kopplung und auch die macht in bestimmten Situationen Sinn. Ich gehe davon aus, dass Du das weißt, noch besser als ich. Ich mag nur nicht das Schwarz/Weiss denken, bzw. verteufeln von bestimmten Vorgehensweisen. Manchmal ist ein Anti-Pattern in einer bestimmten Situation am effektivsten.
  • entwickler schrieb:

    Manchmal ist ein Anti-Pattern in einer bestimmten Situation am effektivsten.


    Beim Fussball ist es auch am effektivsten wenn ich meine Gegner einfach erschiesse. Trotzdem ist das wohl eher keine gute Methode um zu gewinnen.

    Effektivität sollte niemals über Flexibilität stehen

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)