前提：
>在网络堆栈中：
> Controller通常对应一个URL,视图代表页面.
>视图有办法不用CSS Javascript片段重复代码.
>在iOS中：
>一旦进入与UIViewController对应的新屏幕.
>我们有一个UIView组成自己的UIViews
> UIViews与UIViews,UIViewController与UIViews,UIViewController与内联UIViews一起存在
>我们确实将重型或数据逻辑委托给最近的控制器
>感觉大多数在iOS中首先看起来很棒
题：
考虑将视图组合到我的self.view的最佳方法是：
>作为UIView类的视图
>作为UIViewController发生的视图,具有关联的UIView类.
>作为具有内联UIView的UIViewController发生的视图
示例视图层次结构
------------------------------ | A | | | | -------------------- | | | B | | | | | | | | -------------- | | | | | C | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -------------- | | | | | | | -------------------- | | | ------------------------------
[细节具体]我〜不舒服〜经历：
>一个可能[self addView：B_view](如果B只是UIView)
> A也可能[self addView：B_viewController.view](如果B有一个视图控制器)
> A也可能[B setChildView：C_view]
>我们可以有B_viewController.delegate = A& C_viewController.delegate = A.
>我们可以有B_viewController.delegate = A& C_view.delegate = B.
>在所有这些案例共存后,我们必须考虑范围
>我看到C通过长代表链回答了C的问题.
逻辑分散在委托,viewControllers和视图中.
分离问题 – 但如何？
除了可以改善以上经验的“抽象井和关注点分离”这一论点.我相信它的viewController和viewController.view的流失很容易导致广泛的耦合.
这很快变得令人困惑,感觉就像意大利面条,尽管付出了努力但很难控制.
那说,
>解决上述陷阱的最佳做法是什么？
>绝对不应该做什么？
>当代理人有效地说你可以更好地处理这个问题时,我们如何避免长代表链？
解决方法
http://www.cimgf.com/2015/09/21/massive-view-controllers/
除了委托模式,我们还有基于块/闭包的方法,可能有助于清理代码.
一般来说,Robert C. Martin的清洁代码方法在这里可能会有所帮助.通过称为VIPER架构的方式实现它的方法.这是一个关于它的教程.
https://www.objc.io/issues/13-architecture/viper/
目标C,作为一种语言包含委托模式,并且将其用于大多数人的关注是一种标准做法.
欢迎来到iOS平台.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。