您的位置:首页 > 其它

23种设计模式分类+SOLID设计原则+从设计模式角度看MVC框架

2016-04-22 11:45 381 查看
目的:设计模式旨在帮助使用者设计可维护、可扩展、可复用、灵活性好的系统



1.  23中设计模式分类



1.1 创建型模式(5个)

工厂方法模式(Factory Method)

抽象工厂模式 (Abstract Factory)

创建者模式(Builder)

原型模式(Prototype)

单例模式(Singleton)

PS:相信大家都听说过简单工厂模式,他也属于创建型模式中的一种,但是并没有列入到经典的23中设计模式当中,我认为其中有一个重要的原因应该是简单工厂模式严重违背了开闭原则(OPEN-CLOSED Principle)。

1.2 结构型模式(7个,缩写ABCDFFP)

适配器模式(Adapter)

桥接模式(Bridge)

组合模式(Composite)

装饰模式(Decorator)

外观模式(Facade)

享元模式(Flyweight)

代理模式(Proxy)

PS:在7中结构型模式中,一般优先使用组合而非继承,但是并不是说不能使用继承,因为继承毕竟是面向对象的三大特性之一(封装、继承、多态)。继承的场景是随处可见的,但是每一种继承只适合封装一种变化,面对多维变化的场景,如果强行使用多继承的方式来实现,则会造成子类数目爆炸性增长,而使用组合的方式能够使多维变化点能够独立的扩展和变化。

1.3 行为型模式(11个)

模板方法模式(Template Method)

观察者模式(Observer)

状态模式(State)

策略模式(Strategy)

职责链模式(Chain of Responsibility)

命令模式(Command)

访问者模式(Visitor)

中介者模式(Mediator)

备忘录模式(Memento)

迭代器模式(Iterator)

解释器模式(Interpreter)

PS:行为模式又分为行为类模式和行为对象模式,行为类模式采用继承机制在类间分配行为,其中Template Method和Interpreter就是属于行为类模式;行为对象模式使用对象组合而非继承,描述了一组相互对等的对象如何相互协作来完成任何一个单一对象都无法完成的任务,剩下的9中行为模式都属于组合行为模式范畴。






[b]2.  SOLID设计原则
[/b]



[b]2.1 单一职责原则(Single Responsibility Principle)[/b]

每个方法和类有且仅有一个引起变化的理由。带来的好处是如下:

2.1.1 类的复杂性降低

2.1.2 可读性提高

2.1.3 可维护性提高

2.1.4 变更引起的风险降低

2.2 开闭原则(Open Closed Principle)

开闭原则是最基础的原则,是其他5个原则的精神领袖,其重要性体现在以下几个方面:

2.2.1 降低了测试的工作量

2.2.2 提高了代码的复用性

2.2.3 提高了代码的可维护性

2.2.4 符合面向对象开发的要求

2.3 里氏替换原则(Liskov Substitution Principle)

为良好的继承定义了一个规范,包含了如下4层含义

2.3.1 子类必须完全实现父类的方法

2.3.2 子类可以有自己的方法和属性

2.3.3 覆盖或实现父类的方法时输入参数可以被放大

2.3.4 覆写或实现父类的方法时输出结果可以被缩小

2.4 迪米特法则(Law of Demeter 也称 最少知识原则 Least Knowledge Principle)

对类的低耦合提测了明确要求,包含以下4层含义

2.4.1 只和朋友交流(对类而言,朋友类要么是成员变量,要么是输入输出参数)

2.4.2 朋友间也是有距离的

2.4.3 是自己的就是自己的(主要是针对方法和类的关系)

2.4.4 谨慎使用Serializable(属于项目管理范畴)

2.5 接口分离原则(Interface Segregation Principle)

对接口进行规范约束,包含一下4层含义

2.5.1 接口要尽量小

2.5.2 接口要高内聚

2.5.3 定制服务

2.5.4 接口设计是有限度的

另外,对接口进行分离是应该要注意:接口要尽量小的同时必须要满足单一职责原则

2.6 依赖倒置原则(Dependency Inversion Principle)

包含以下三层含义:

2.6.1 高层模块不应该依赖低层模块,两者都应该依赖其抽象

2.6.2 抽象不应该依赖细节

2.6.3 细节不应该依赖抽象

3.  从设计模式角度看MVC框架

模型层(MODEL),模型持有所有的数据,状态和程序逻辑。模型层实现了观察者模式,当状态改变时,相关对象将持续更新,并通知视图层改变显示,可以完全独立于视图层和控制层。

视图层(VIEW),用来呈现模型,视图层通常直接从模型中取得它需要显示的状态和数据。视图层通常会实现组合模式,视图是GUI组件(标签、窗口、文本输入等)的组合,顶层的组件包含其他组件,直到叶子节点。

控制层(CONTROL),取得用户的输入并解读其对模型的意思。视图层和控制层一起实现了经典的策略模式,视图是一个对象,可以被调整使用不同的策略,而控制层提供了策略。视图层只关心系统中的可视部分,对于任何界面行为,都委托给控制器处理。使用策略模式也可以让视图层和模型层之间的关系解耦,因为控制层负责和模型层交互交互来传递用户的请求,对于工作究竟是如何完成的,视图层毫不知情。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  设计模式