iOS架构设计

话说天下大势，分久必合，合久必分。周末七国分争，并入于秦。及秦灭之后，楚、汉分争，又并入于汉。汉朝自高祖斩白蛇而起义，一统天下，后来光武中兴，传至献帝，遂分为三国 —- 《三国演义》

关于iOS的架构，看多了MVVM，VIPER,MVC，MVP，MVCS….的介绍文章。真正实践下来的估计也就是MVC和MVVM了。MVC是系统自带的框架，自然用的多。而MVVM解决了Controller臃肿的问题，再加上神器RAC也被很多团队接纳，甚至有一段时间出现了很多的文章鼓吹该模式如何如何了得。而在设计或者采纳一个架构的时候，我们到底在思考些什么？

设计各个类的职责和他们之间的关系。

用个比较晦涩的说法是：关键概念抽象与概念关系设计。打个盖房子的比方吧，关键概念抽象就是搞到钢筋混凝土砖瓦石块的基础材料，而概念关系设计就是如何组织这些基础材料：钢筋为骨，水泥为胶，添砖加瓦为墙面，然后一个房子的雏形就有了。其实，在我理解,『架构』设计也应当类似。从一个宏观的层面进行分析和抽象，找到合适的概念，这是分解，而后再把这些概念通过各种关系操作搞到一起，这是合成。分分合合中满足一定的质量约束，我们有了一个架构。

希望满足的质量约束

提高复用度

懒是第一生产力

这句话依稀记得是之前的GM说的，印象颇深。因为，仔细想想，我们在做设计和编码的时候，都有一个原始的冲动就是少写点代码。最好，产品经理需求变动之后，我们不改代码就能够满足他们的需求。任他天翻地覆，我自以不变应万变。而黄粱一梦惊破醒，现实如此骨感。往往做业务开发的时候，疲于奔命的改改改。其实，我们的内心也是抗拒这样的，少改点多好。那怎么才能少改点？

一个比较直接的做法就是：拿来就用。就是我们一直在说的组合模式。假设轮子都已经造好，要造个车，就只需要考虑如何去构架这个车的骨架和去实施，而不用去重新发明轮子（当然，轮子质量约束不满足需求的情况下是得重新发明的）。没有过多的思维负担和实施负荷，当然就省事了。我们拥有越多的轮子，我们就能越省事。复用啊复用，这个懒的入门宝典。

于是提高整个系统和系统内部组成单元（模块，类，函数。。。）的复用性就是一个非常重要的质量约束。通常情况下，谈及复用我们想到更多的是类和函数。我们之前写过一个什么什么功能的函数了，现在拿来就用好了。其实，还有更高一个思维层次的概念：业务逻辑。我们希望业务逻辑中的代码也是可以复用的。比如一个ViewController的渲染逻辑（把整个VC的样式包括nav和view都渲染成红色）。我们希望在写一个VC的时候，能够很方便的复用之前写的这样的业务逻辑，即使VC的根view已经发生了改变，不再是原来的类型。

足够的扩展性

新的东西被引入是永恒不变的事情。可能是新的页面，新的业务逻辑，新的功能….当新的需求的到达的时候，我们的架构是否能够快速的接纳他们，以优雅而且高效的方式来实现他们？而不是，每次新的功能来了，要么伤筋动骨的大动干戈；要么削足适履，凑合凑合得了。

我们希望我们的代码能够有序的生长。脉络清晰，每一个新功能都能够在原有的架构中找到自己合适的位置。于是架构的可扩展性（也可以理解为代码的自动化）也是要追求的一个质量约束。这不是简单的向前兼容，向后兼容的问题。而是要能够以最小的代价，承载更多的需求。

关于可扩展性，更喜欢用函数来比喻。

f(x) = x^2 x属于R

简单的函数关系，对于无论什么样属于R的自变量x，我们都能准确的得到因变量f(x)的值。而一个理想状态是，如果我们的架构如一个函数一般，对于未来的变化都进行了合适的抽象，无论你输入是什么，都有对应的输出，那该多好。

其他属性

前面所说的两个属性，更多的是从系统的角度来思考的。当然我们从不同的角度来思考，还会要求我们的架构能够满足不能的质量约束。从运行的角度，我们希望CPU、内存、磁盘利用率好，没有卡顿，从用户的角度思考我们希望界面流畅。饕餮一样，我们总是贪得无厌的想让这个架构完美。然而，现实很骨感，我们只能先从几个入手。

BY:yishuiliunian