一 为什么设计模式
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
说白了就是前辈们写项目的经验总结,怎样少犯错,怎样让代码更简洁,经常见到的代码可不可以优化到框架里?经常有的人会把代码逻辑写到controller里面,就好像我在写google reply时候,把所有的逻辑放到一个controller里面,各种if判断各种赋值语句,自己写的很顺手,出问题时候排查都不知道在哪里.应用设计模式可以有效避免再写出这种事后连自己都看不懂的代码.
二 设计原则
既然是模式,就是可以复制的,则必然有一定的脉络可供遵循.设计原则就是这些脉络.
1. 单一职责原则 single responsibility principle
不要存在多于一个导致类变更的原因.一个文件负责一个功能,避免出现修改一个文件影响几个功能的情况.比如有 分类,排序,唯一三个功能,不要在一个方法里同时实现这三个功能,这样当某一个功能出现问题进行修改时候,不会影响其他两个正常的功能,低耦合.
2. 里氏替换原则 Liskov Substitution principle
** 1988年,麻省理工的Barbara Liskov 提出.
如果对每一个类A,都有类A1 ,使得A1具有A中所有的程序,且A中所有的程序行为没有变化,那么A1是A的子类.
特点如下:
子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法;子类中可以增加自己的独有方法;当子类的方法重载父类的方法时,方法的形参要比父类的输入参数更宽松;当子类的方法实现父类的抽象方法时,方法的后置条件即返回值要比父类更加严格.
3. 依赖倒置原则 Dependence Inversion Principle
** 核心是面向接口编程.
高层模块(业务模块)不应该依赖低层模块(核心模块),二者都应该依赖其抽象,抽象不应该依赖细节,细节应该依赖抽象.使用接口降低不同文件之间的耦合度.商业化ad 项目里广告api 的接入程序就是一个简单的例子.所有不同类继承一个抽象接口. 依赖倒置不一定是接口,也可以是构造方法如CI ,或者 抽象类(Yii??).
4. 接口隔离原则 Interface Segregation principle
如果接口I 对于依赖它的接口来说有完全不需要的抽象方法,则接口I 不是最小接口.需要将接口I 拆分成独立的几个接口.也就是接口独立原则
** 与单一职责的区别, 单一职责是具象实现层面,接口隔离是逻辑控制层面.
5. 迪米特法则 Law of Demeter
** 不要和陌生人说话法则.个人感觉不符合互联网开放的特性,无疑会增加代码逻辑的复杂度,更多的setter和 getter ,更多的new model() 反而会增加程序通信成本.和使用人员的理解成本.(Yii的各种private,打断了不少新人进一步理解的念头吧??!)
一个对象应该对其他对象保持最少的了解.对于类自己来说就是减少public 封装,不对外泄露任何信息,
6. 开闭原则 Open Close principle
一个文件,类,模块,函数等应该对扩展开放,对修改关闭.即尽量在原有的基础上升级扩展,而不要修改.
//My submit
设计原则里开闭原则是总纲,单一职责,接口隔离,迪米特law,barbara里氏替换,依赖倒置 这些是小法则,遵循6个原则设计出来的框架即使暂时不好用,逻辑上也是清晰的.
** 简称SOLID single open lisko interface demeter(dependency inversion)
三 几种设计模式
原则是指导思想,具体的方法论就是设计模式.设计模式有三类型,23种.
创建型模式:单例模式,抽象工厂模式,建造者模式,工厂模式,原型模式
结构型模式:适配器模式,桥接模式,装饰模式,组合模式,外观模式,享元模式,代理模式
行为型模式:模板方法模式,命令模式,迭代器模式,观察者模式,中介者模式,备忘录模式,解释器模式,状态模式,策略模式,职责链模式,访问者模式
当然现在写框架必然MVC了. MVC 不是23种设计模式里面的任何一种,原因当然是设计模式概念提出来的时候作者没有把MVC理解为一种模式.而是几种模式的组合应用.
**最早的MVC在1979年面世,那时候没有win,CLI下运行,model 处理数据,view 负责展示,controller 类似代理把数据和展示粘起来,值得一提的是当时的view和controller都监控model ,一旦model 层变化,其他的也都变化.
1 GoF (Gang of Four，四人组， 《Design Patterns: Elements of Reusable Object-Oriented Software》/《设计模式》一书的作者： 2 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides)并没有把MVC提及为一种设计模式，而是把它当做“一组用于构建用户界面的类集合”。 3 在他们看来，它其实是其它三个经典的设计模式的演变：观察者模式(Observer)(Pub/Sub), 策略模式(Strategy)和组合模式(Composite)。 4 根据MVC在框架中的实现不同可能还会用到工厂模式(Factory)和装饰器(Decorator)模式。
1 正如我们所讨论的，models表示应用的数据，而views处理屏幕上展现给用户的内容。为 2 此，MVC在核心通讯上基于推送/订阅模型(惊讶的是 在很多关于MVC的文章中并没有提及 3 到)。当一个model变化时它对应用其它模块发出更新通知(“publishes”)，订阅者 4 (subscriber)——通常是一个Controller，然后更新对应的view。观察者——这种自然的观 5 察关系促进了多个view关联到同一个 model。 6 7 8 对于感兴趣的开发人员想更多的了解解耦性的MVC(根据不同的实现)，这种模式的目标之一就 9 是在一个主题和它的观察者之间建立一对多的关系。当这个 主题改变的时候，它的观察者也会 10 得到更新。Views和controllers的关系稍微有点不同。Controllers帮助views对不同用户的 11 输 入做不同的响应，是一个非常好的策略模式列子。
所以MVC 是几种模式的组合,我们自己在实现MVC的时候可以借鉴23种设计模式组合出我们自己的使用的框架.
四 拓展
现在框架的发展不止有MVC,还有MVVC等,有兴趣的可以自行百度下,也可以留言共同探讨.