设计模式以前学了几个简单的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)
5603
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
