任何设计模式的提出都是为了更好、更灵活的解决问题。存在即合理，没有绝对的好坏之分……
前几天支付宝的大神给做培训，先来剖析一波人的心理，否则谈什么貌似都没有用
- 程序员都是自信的，并且觉得自己很牛逼，看了别人写的东西觉得垃圾，劳资要重构之（大神原话是“程序员都觉得自己很牛逼，其实我也这样”，我表示赞同）
zhuangB.jpg
- 敏捷开发虽然要以人为本，但是跟程序员的素养有极大的关系，要在一个公司推行-————太难
chedan.jpg
- 程序员总会认为频繁变更需求的经理傻逼，我好不容易写完了，你又要改成这样
tiaolou.png
我有话要说：
- 自信倒也不一定是坏事，但是一定要理智。
- 素养要培养起来跟一个人的性格有关，总之还是很难的。
- 至于产品为啥老变更需求，我想说的是：不变更需求、跟不上节奏的产品肯定不是合格的产品。一个小公司的产品完全能够决定一个公司的死活。
- 一个程序要做到灵活应对产品的需求变更，不是拿到变更需求就去找产品吵架、砍功能，公司花钱雇你来解决问题，不是制造问题。所以学习各种设计模式能够更灵活的应对需求变更，同时对自己的能力也会有很大的提升。
- 敏捷开发 在一个公司很难推行的主要原因我感觉有两个，一个是 工作能力，一个是 职业素养。很多公司喜欢启用新人的原因我个人感觉是职业素养更容易培养吧，而能力是迟早能提高的事。只是猜测哈，我不搞人事……
我个人的思路是：组件化设计-->子模块化设计-->MPC设计-->MVC、MVP设计。当然怎么写要看业务的复杂度了，每个人的想法不同。
- MVC：模型(Model)－视图(View)－控制器(Controller)
- MVP：提供数据(Model)-负责显示(View)-负责逻辑的处理(Presenter)
- MPC：模块(Module)-交互协议(Protocol)-协调器(Coordinator)
以前为了面试，死记硬背一堆乱七八糟的设计模式，然而并没有什么卵用，其实……
工作时间长了，自然就会把复杂的东西分开写了，我用了半年的MVP，直到听支付宝大神讲课的时候才知道现在的写法是MVP。
百度播放的DEMO就用的MVP，我一直以为我原创的设计模式呢。
不用多讲，代码写多了，自然理解，不用刻意去学，但是我还是要说说废话的。
提出 MPC 这个概念的时候我心里也突突，我是吃了熊心豹子胆了么，MVC、MVP、MVVM等等的设计模式都是大神们工作总结出来的，我怎么就敢独立提出一个构想MPC，想想说干还得干啊。
在简书上看到一遍文章 太在意别人的看法，最后活成了自己讨厌的模样 决定还是要写下去的， 你有你的看法，我有我的选择
tanqin.gif
闲话少说，我们进入正题
以前搞组件化开发的时候我画了个很糙的图，拿来用用。参照大神们的思路，结合我自己的理解，然后实践了半个多月，发现都行得通。
我特别希望大家指点我的组件化开发的专题，因为第一次实践、踩坑，也希望大家多给我建议。
zujianhua.png
MPC从字面更倾向于组件化开发的一种设计模式，但是用在复杂业务上开发也很好，
把一个应用拆分为多个独立的模块可以方便的分配工作进行合作开发。
MPC从MVP上演进，针对IOS开发所设计。
比如一个复杂的页面，我们进行拆分为多个模块，每个模块用MVC、MVP模式开发，然后定义交互协议，再由协调器统一调用
本文我结合实际的项目，从一个简单项目到复杂项目的演变，如何从 MVC 到 MVP 再到 MPC 这三种模式逐渐过渡。不能说是最好的，只是我慢慢的摸索出来的这么一个思路，仅供参考。
说MVP比MVC好，我不赞同，任何设计模式都有其独特之处，特别简单的功能如果用MVP反而适得其反；
稍微复杂的功能如果用MVC，那就显得特别的臃肿，比如头条，百度外卖，这种复杂的APP结构，MVP显然相对合理一些。
前几天听前支付宝的安卓工程师的课程，讲述了程序员的素养和APP架构，决定自己要写一篇了，因为安卓的东西并不能都应用到IOS上。随着业务的庞大，MVP逐渐体现出来其优势，从单个复杂页面、复杂业务再到组件化开发都渗透着MVP的思想。
我先从一个简单的产品，变更到复杂业务的时候，如何从MVC到MVP，再升级到我个人理解的MPC设计模式
提一个需求
老板说我要做个APP，美食类的，然后产品就咔咔咔的去设计了
按照我个人的观念，文章长了就没心思看了，技术跟扯皮铺垫的文章要分开。下一篇文章会从产品变更需求的角度去剖析MVC、MVP、MPC再到组件化的演变。
网友评论