设计模式概要

  1. 云栖社区>
  2. 博客>
  3. 正文

设计模式概要

ghost丶桃子 2016-05-18 16:04:55 浏览798
展开阅读全文
看设计模式有段时间了,但是有没有多少机会使用。结果陷入到了“看了忘忘了再看”的恶性循环,
虽然我们本来就应该温故知新的。我们能不能找到一些更好的方法呢?
有一种叫做“自顶向下”的思路我们都很熟悉的可以拿来试试。

设计的原则
要学设计模式,设计的原则就不得不学。这里只做简单的介绍。需要更加详细的说明可以参考吕震宇的博客,非常的不错!
1. 单一职责原则(The Single-Responsibility Principle
 一个类只有一个引起变化的原因。可以想象,如果一个类承担了一个 以上的职责,
那么任何一个职责的变换都会影响到这个类所承担的其他职责。这是一种紧耦合的设计。
2.开放封闭原则(The Open/Closed Principle
一个软件实体(类,模块,函数等)应该对扩展开放,而对修改封闭。
那么怎么才能做到这一点呢?关键是抽象。当模块依赖于和一个固定的抽象体时,它对更改时封闭的,
而它可以通过派生新类扩展模块的行为。
3.里氏替换原则(The Liskov Substitution Principle
子类型必须能够替换他们的基类型
4.依赖倒置原则(The Dependency-Inversion Principle)
    a.高层模块不应该依赖于低层模块,二者都应该依赖于抽象.
    b.抽象不应该依赖于细节。细节应该依赖于抽象。
从代码重用的角度讲,我们更希望重用的是高层的抽象出来的模块。当高层模块依赖于低层模块的时候,
在不同的环境对高层模块使用的也会受到很大的制约。

“Don't call us,we'll call you。”用低层模块实现高层模块中的声明并被高层模块调用的接口。
5.接口分离原则(The Interface Segregation Principle)
过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。 
使用多个专门的接口比使用单一的总接口总要好。换而言之,从一个客户类的角度来讲:
一个类对另外一个类的依赖性应当是建立在最小接口上的。

补充:我们还需要搞清楚IS-A和HAS-A。
"Is-A"是严格的分类学意义上定义,意思是一个类是另一个类的"一种"。而"Has-A"则不同,
它表示某一个角色具有某一项责任。 


模式是如何组织的
模式的组织模式有很多种。网上很多文章会直接把设计模式分为创建型模式,结构型模式,行为型模式
所以我们主要讨论这些模式的分类方式。
分类的理由何在?两个标准:一个是目的,一个是范围。
根据目的模式可以分为,创建模式、结构模式和行为模式,也就是我们上面提到的。创建型模式关心对象的创建过程,
结构型模式涉及的是类和对象的组成,行为模式描述的是类和对象的交互以及职责分配的方式。
第二个标准,称为范围(Scope)。范围描述了模式主要是应用于对象,
还是主要应用于类。“类模式”主要处理类与其子类的关系,这种关系是通过继承得来的,因此它们是静态-固定、由编译时决定的;
“对象模式”处理对象关系,这种关系是运行时决定的,是动态关系。几乎所有的模式都在某种程度上使用了继承,
因此只有那些标明为“类模式”的模式才重点关注类关系,
大多数模式都在“对象模式”范畴。

“创建性类模式”将部分的对象创建工作延迟到了子类,而“创建性对象模式”将其延迟到了另外的对象。
“结构性类模式”应用继承机制来合成类,
而“结构性对象模式”则规定了装配对象的方式。
行为性类模式用继承机制来描述算法和控制流,而行为性对象模式则规定一组对象如何合作以完成某项单一对象不能达成的任务




参考:
http://blogger.org.cn/blog/more.asp?name=torrent&id=6725
http://www.cnblogs.com/zhenyulu/category/6930.html?Show=All
Agile Principles, Patterns, and Practices in C# author:  Martin C. Robert, Martin Micah
欢迎加群互相学习,共同进步。QQ群:iOS: 58099570 | Android: 330987132 | Go:217696290 | Python:336880185 | 做人要厚道,转载请注明出处!

网友评论

登录后评论
0/500
评论
ghost丶桃子
+ 关注