23种 设计模式---面向对象的基本原则-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

23种 设计模式---面向对象的基本原则

简介:

软件开发原则

原则1:不要重复自己(Don’t Repeat Yourself,DRY原则) 
这个原则非常重要,换言之,就是不要写重复的代码。

原则2:尽量简单、一目了然(Keep it Simple Stupid,KISS原则)

所以做到简单的同时,还要做到一目了然。你也可以这样理解,将一个软件做得连白痴都会用。这就是用户体验的最高境界了。如何做到简单且一目了然呢?这要归结到软件开发的可维护性和可理解性

原则3:适可而止(You Ain’t Gonna Need It,YAGNI原则) 
YAGNI原则指的是只需要将应用程序必需的功能包含进来,而不要试图添加任何其他你认为可能需要的功能。 在一个软件项目中,往往80%的时间花费在20%的功能上。当你准备列出一个项目清单时,试着考虑以下问题:
通过降低抽象的层级,来实现低复杂度,根据特性将功能独立出来,适度接受非功能性需求,识别耗时的任务,并摆脱它们

 

设计模式以前学了几个简单的Factory, Singleton等, 前一段时间决定系统的学习一下,耗时两个月, 读了3本书,包括<Java与模式>,<大话设计模式>, <head first design pattern>, 还参考了大量的网友的经验和思想, 最终把自己认为精华的部分,记录在blog中. 当然我自己也学的不是很深入, 需要在项目中逐渐体会, 同时也想多看看优秀的源码,它们都是设计模式非常好的教材. 所谓知之为知之, 不知为不知, 是知也.
需要提醒行业新朋友的是:  
1 设计模式不是新技术, 它是前人总结的软件设计思想. 这就好比盖楼房, 砖瓦结构可以盖, 框架结构也可以, 但是砖瓦结构肯定盖不了100层高楼.
2 设计模式不局限于语言 , java可以, c++,c# delphi可以, php, JavaScript也可以. 正如我不懂c#, 但是我读的<大话设计模式>却是以c#来讲解的, 但我觉得这不影响我理解设计模式.
3 学习设计模式不是不是把类图画出来就算学完了, 关键是看一个设计模式是怎么做到把握需求,拥抱变化的.

 

为什么要知道面向对象的基本原则呢? 因为我们考察一个设计模式好不好, 一个设计优秀不优秀, 用基本原则来检验.


单一职责原则(Single Responsibility Principle): 就是一个设计或实体应该只做一件事/只描述一个事物, 比如一个类Cat, 那么读代码的人应该觉得这个类始终都在说猫,而不是扯到狗身上去了, 虽然猫狗有时候会打架,但那也只是关联关系. 这与现实中也很相似, 如果你专著于一件事, 你会做得很出色.


开放封闭原则(Open-Close Principle): 一个实体应该对拓展开放,对修改封闭. 就是说, 任何一个系统, 需求总是在变的, 但是我们不能在任何需求到来的时候都把原有的设计推倒了重来, 而是尽可能的在保持相对稳定的情况下, 进行拓展. 事实上这也是世间万物的演变规律, 任何生物,都是从当初的单细胞生物随着环境的变化而逐渐演化过来的, 而不是说, 一旦环境变化, 则变异一个全新的形态出来. 在软件行业中, 这一原则体现在知识的积累, 系统的演化更新上. 优秀的平台(如java), 框架(如struts, spring), 都是由最初的雏形, 从版本0.1开始演化过来.


里氏替换原则(Liskov Substitution Principle): 子类必须能够替换掉他们的父类型. 这个原则考验的是继承结构的合理性, 如果子类不能完全取代父类的位置, 则继承结构就不合理.
依赖倒置原则(Dependency Inversion Principle): 设计应该依赖于抽象,而不能依赖于具体。也就是说要面向接口编程。 因为接口代表着功能,代表着规范,不易变。而实现却会随着时间和环境发生变化。比如银行,自从有银行开始,它就有存款和贷款业务, 那么存款和取款就是它的接口。但是不同的时代,具体的实现方式大有不同,以前都要到银行柜台上去办理, 后来有了支票, 现在有了电子帐户。如果我们有一个设计要使用银行的业务,不应该依赖于具体的某种实现方式,而应该依赖于接口。

接口隔离原则(Interface Seperation Principle): 使用多个专门的接口比使用单一的总接口要好. 系统对外提供宽窄不同的接口以应对不同的客户。

1.单一职责原则(SRP)

单一职责原则的核心思想就是:系统中的每一个对象都应该只有一个单独的职责,而所有对象所关注的就是自身职责的完成。它的英文缩写是SRP,英文全称是Single Responsibility Principle。

其实单一职责原则的意思就是开发人员经常说的"高内聚、低耦合"。也就是说,每个类应该只有一个职责,对外只能提供一种功能,而引起类变化的原因应该只有一个。在设计模式中,所有的设计模式都遵循这一原则。

2.开闭原则(OCP)

开闭原则的核心思想就是:一个对象对扩展开放,对修改关闭。它的英文缩写是OCP,英文全称是Open for Extension,Closed for Modification。

其实开闭原则的意思就是:对类的改动是通过增加代码进行的,而不是改动现有的代码。也就是说,软件开发人员一旦写出了可以运行的代码,就不应该去改变它,而是要保证它能一直运行下去,如何才能做到这一点呢?这就需要借助于抽象和多态,即把可能变化的内容抽象出来,从而使抽象的部分是相对稳定的,而具体的实现层则是可以改变和扩展的。

3.里氏替换原则(LSP)

里氏替换原则的核心思想就是:在任何父类出现的地方都可以用它的子类来替代。它的英文缩写是LSP,英文全称是Liskov Substitution Principle。

其实里氏替换原则的意思就是:同一个继承体系中的对象应该有共同的行为特征。里氏代换原则关注的是怎样良好地使用继承,也就是说不要滥用继承,它是继承复用的基石。

4.依赖注入原则(DIP)

依赖注入原则的核心思想就是:要依赖于抽象,不要依赖于具体的实现。它的英文缩写是DIP,英文全称是Dependence Inversion Principle。

其实依赖注入原则的意思就是:在应用程序中,所有的类如果使用或依赖于其他的类,则都应该依赖于这些其他类的抽象类,而不是这些其他类的具体实现类。抽象层次应该不依赖于具体的实现细节,这样才能保证系统的可复用性和可维护性。为了实现这一原则,就要求开发人员在编程时要针对接口编程,而不针对实现编程。

5.接口分离原则(ISP)

接口分离原则的核心思想就是:不应该强迫客户程序依赖它们不需要使用的方法。它的英文缩写是ISP,英文全称是Interface Segregation Principle。

其实接口分离原则的意思就是:一个接口不需要提供太多的行为,一个接口应该只提供一种对外的功能,不应该把所有的操作都封装到一个接口当中。

6.迪米特原则(LOD)

迪米特原则的核心思想就是:一个对象应当对其他对象尽可能少的了解。它的英文缩写是LOD,英文全称是Law of Demeter。

其实迪米特原则的意思就是:降低各个对象之间的耦合,提高系统的可维护性。在模块之间,应该只通过接口来通信,而不理会模块的内部工作原理,它可以使各个模块耦合程度降到最低,促进软件的复用。

7.优先使用组合而不是继承原则(CARP)

优先使用组合而不是继承原则的核心思想就是:优先使用组合,而不是继承。它的英文缩写是CARP,英文全称是Composite/Aggregate Reuse Principle。

其实优先使用组合而不是继承原则的意思就是:在复用对象的时候,要优先考虑使用组合,而不是继承,这是因为在使用继承时,父类的任何改变都可能影响子类的行为,而在使用组合时,是通过获得对其他对象的引用而在运行时刻动态定义的,有助于保持每个类的单一职责原则。


更多原则不一一细说. 而且如果没在实践中体会他们, 记住文字定义也没有意义.

创建型:

1. 单件模式(Singleton Pattern)

2. 抽象工厂(Abstract Factory)

3. 建造者模式(Builder)

4. 工厂方法模式(Factory Method)

5. 原型模式(Prototype)

结构型 :

6. 适配器模式(Adapter Pattern)

7. 桥接模式(Bridge Pattern)

8. 装饰模式(Decorator Pattern)

9. 组合模式(Composite Pattern)

10. 外观模式(Facade Pattern)

11. 享元模式(Flyweight Pattern)

12. 代理模式(Proxy Pattern)

13. 模板方法(Template Method)

14. 命令模式(Command Pattern)

15. 迭代器模式(Iterator Pattern)

行为型 :

16. 观察者模式(Observer Pattern)

17. 解释器模式(Interpreter Pattern)

18. 中介者模式(Mediator Pattern)

19. 职责链模式(Chain of Responsibility Pattern)

20. 备忘录模式(Memento Pattern)

21. 策略模式(Strategy Pattern)

22. 访问者模式(Visitor Pattern)

23. 状态模式(State Pattern)

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章
最新文章
相关文章