Grundsatzfrage über die Aufteilung der Klassen

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

  • Grundsatzfrage über die Aufteilung der Klassen

    Guten Abend,

    auf die Gefahr hin, dass ich mich mit dieser Frage sehr "blamiere", aber ich glaube ich habe das objektorientierte Programmieren etwas missverstanden.

    Wenn ich ein Programm schreibe beginne ich zB mit einer Klasse vom Typ UIViewController.
    Nun füge ich 3 UIViews hinzu. Die ersten Beiden teilen sich den Bildschirm, der 3. ist bildschirmfüllend jedoch bisher hidden.

    im ersten View ist zB eine Tabelle, im 2. ein Button - beim Klick dieses Buttons erscheint der 3. UIView mit einem Button der Diesen wieder versteckt.

    So nun meine simple aber essentielle Frage: Wo schreibe ich alle Methoden rein? Bisher hätte ich für ein solches Szenario @propertys für alle Views und Buttons in der Header-Datei des UIViewControllers geschrieben und analog alle Methoden in die .m Datei, _view3.hidden = YES gesetzt etc.

    Alternativ könnte man ja theoretisch auch jeden View als eigene Klasse schreiben und darin die jeweiligen Buttons "ansteuern" und zB in der Klasse CustomView2 einen Konstruktor zur Klasse CustomView3 erstellen und darin die jeweiligen propertys ändern.

    Vielen Dank für eure Hilfe!

  • In der Regel sollte der Viewcontroller die Eingaben der Buttons auswerten; also gehören die Methoden in den Viewcontroller.

    Views sollten nur dann Actions entgegennehmen, wenn Sie diese Ereignisse (z. B. über das Versenden von Delegatenachrichten) weiterleiten. Ein Beispiel hierfür sind Tableviews bzw. -zellen, die mehrere Buttons (z. B. zum Löschen) besitzen. Der Tableview nimmt zwar deren Actionnachrichten entgegen, leitet sie aber immer schön brav an das Delegate weiter.

    Sobald in Deinen Views Businesslogik, wie beispielsweise das Ändern von Modellobjekten, steht, bist Du auf dem Holzweg. Die Viewschicht kennt weder Controller noch Model.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    In der Regel sollte der Viewcontroller die Eingaben der Buttons auswerten; also gehören die Methoden in den Viewcontroller.

    Views sollten nur dann Actions entgegennehmen, wenn Sie diese Ereignisse (z. B. über das Versenden von Delegatenachrichten) weiterleiten. Ein Beispiel hierfür sind Tableviews bzw. -zellen, die mehrere Buttons (z. B. zum Löschen) besitzen. Der Tableview nimmt zwar deren Actionnachrichten entgegen, leitet sie aber immer schön brav an das Delegate weiter.

    Sobald in Deinen Views Businesslogik, wie beispielsweise das Ändern von Modellobjekten, steht, bist Du auf dem Holzweg. Die Viewschicht kennt weder Controller noch Model.


    Ok gut, ich frage mit folgendem Hintergrund:

    Mittlerweile ist meine App sehr umfangreich. In Dieser sind verschiedene "Pages" in einem UIScrollView miteinander verbunden. Auf der 1. Seite kommt eine Suche, auf der 2. eine Tabelle, auf der 3. zB ein Menü etc.. und das artet mittlerweile zu einer sehr komplexen Klasse aus. Ist das anders realisierbar? Mit mehreren Controllern schafft man halt keinen scrollbaren Übergang (oder doch?). (über Sinn und Unsinn lässt sich bei diesem Konzept natürlich streiten :D)

  • macmoonshine schrieb:

    Hört sich nach einem Fall für UIPageViewController oder eingebetteten Viewcontrollern an.


    Eingebetteter UIViewController - also eine Funktion wie addChildViewController? Könnte ich dann einfach einen UIScrollview über bildschirmfüllende UIViews erstellen und Denen den obersten View der jeweiligen SubViewController hinzufügen?

    Quellcode

    1. [self addChildViewController:subViewController];
    2. [self.view1 addSubview:subViewController.view];