因为假如你不关心架构,那么总有一天,需要在同一个庞大的类中调试若干复杂的事情,你会发现在这样的条件下,根本不可能在这个类中快速的找到以及有效的修改任何bug.当然,把这样的一个类想象为一个整体是困难的,因此,有可能一些重要的细节总会在这个过程中会被忽略。如果现在的你正是处于这样一个开发环境中,很有可能具体的情况就像下面这样:
-
这个类是一个UIViewController的子类
-
数据直接在UIViewController中存储
-
UIView类几乎不做任何事情
-
Model 仅仅是一个数据结构
-
单元测试覆盖不了任何用例
以上这些情况仍旧会出现,即使是你遵循了Apple的指导原则并且实现了其 MVC(模式,所以,大可不必惊慌。Apple所提出的 MVC 模式存在一些问题,我们之后会详述。
在此,我们可以定义一个好的架构应该具备的特点:
-
任务均衡分摊给具有清晰角色的实体
-
可测试性通常都来自与上一条(对于一个合适的架构是非常容易)
-
易用性和低成本维护
为什么采用分布式?
采用分布式可以在我们要弄清楚一些事情的原理时保持一个均衡的负载。如果你认为你的开发工作越多,你的大脑越能习惯复杂的思维,其实这是对的。但是,不能忽略的一个事实是,这种思维能力并不是线性增长的,而且也并不能很快的到达峰值。所以,能够战胜这种复杂性的最简单的方法就是在遵循 单一功能原则 的前提下,将功能划分给不同的实体。
为什么需要易测性?
其实这条要求对于哪些习惯了单元测试的人并不是一个问题,因为在添加了新的特性或者要增加一些类的复杂性之后通常会失效。这就意味着,测试可以避免开发者在运行时才发现问题----当应用到达用户的设备,每一次维护都需要浪费长达至少[一周](http://appreviewtimes.com)的时间才能再次分发给用户。
为什么需要易用性?
这个问题没有固定的答案,但值得一提的是,最好的代码是那些从未写过的代码。因此,代码写的越少,Bug就越少。这意味着希望写更少的代码不应该被单纯的解释为开发者的懒惰,而且也不应该因为偏爱更聪明的解决方案而忽视了它的维护开销。