iOS - 处理大型且不断增长的UIViewController类

时间:2013-02-07 10:44:08

标签: ios oop model-view-controller uiviewcontroller

我有一个UIViewController随着时间的推移已经添加了很多委托事件,这使得控制器类非常大。 UIViewController类包含很多视图管理方法,这些方法从事件委托方法调用,以管理控制器正在管理的UIView。

我现在正在向该类添加更多UIActionSheet委托事件。我的控制器类越来越大,我想我应该打破UIActionSheet委托事件并将它们放在一个单独的委托类中。然后,这个单独的委托类将必须回调到视图控制器类,以使视图控制器相应地调整视图,使用视图控制器中的视图管理方法。 (视图控制器访问视图所代表的单独模型对象。)

我可以看到采用这种突破方法的利弊。向控制器添加越来越多的委托事件感觉是错误的,但是为不同类别的事件创建单独的类然后需要回调到控制器中也似乎引入了不必要的复杂性和混淆层。大型控制器类“简单明了”但感觉不对,而使用多个不同的委托类会稍微复杂一些,但会导致较小的类。

任何人都可以在这个主题上提供一些智慧的话语,并且可能会指出我对这个问题进行一些特定于iOS的阅读吗?

非常感谢。

2 个答案:

答案 0 :(得分:0)

我对此事的处理方法是:

  1. 让它发挥作用
  2. 制作切肉刀
  3. 回到1。 (如果您在某个领域有经验,则1和2都在同一回合中)
  4. 因此,如果代码工作app看起来不错,但你发现某些类有100个方法,所以尝试不同的设计模式(如果你还没有)并使用这些切割器的想法将代码分离成不同的类,代表,如有必要,将它们封装起来。

    http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
    

    以防万一链接到Cocoa Design模式建议,我不时会查看Pro objective c design patterns for ios。可能不是最好的书,但它基于ios上下文中的“四人帮”设计模式。

    希望这有助于至少某种方式,

    干杯

答案 1 :(得分:0)

最后,我创建了一些额外的类来处理特定的UIActionSheet实例。我创建了一个基类,然后为主控制器中的每个UIActionSheet需求创建了子类。

最终结果看起来很整洁,并没有增加太多的复杂性。