记得刚开始学编程的时候就看过设计模式相关的书籍，虽然当时有很多地方都不理解，但是建立了早期对架构设计的意识，让后面的学习和工作中受益匪浅，最近两年也一直在做架构设计方面的工作，解开了之前很多的困惑，也形成了一些自己的思想，我需要把自己零散的想法系统的整理出来，如果能对大家有帮助当然更好了。为什么选择设计模式？因为架构设计是一个很宽泛甚至对于有些人是一个很空虚的领域，设计模式的好处就在早就已经有些很成熟被大家认可的模式。既然已经有了很成熟的模式我为什么还要重复造轮子呢？目前网上很多关于设计模式的文章都是讲解各个模式的规则、目的，很少有直接应用到实际工程的例子，所以我在设计模式后面加了个最佳实践，目的就是通过工程实践把自己在架构设计方面的积累转换成大家容易理解和熟悉的设计模式来表达出来。
个人对学习设计模式的一点建议设计模式并不是短期就能搞懂的知识，甚至都没办法说一个人会不会设计模式，因为设计模式没有绝对的对错，只有不同的理解，以及理解的深浅，学习设计模式可能会是一个循环的过程：理论-》实践-》总结-》理论，不要怕学点设计模式就拿出去在项目中硬套会被笑话，谁都有这个过程，怕就怕在意识不到这是一个渐学渐深的过程，过早的以为自己已经掌握的足够多了。
面向对象六大设计原则废话扯完需要来点实际的了，之所以在开篇里介绍面向对象六大设计原则，主要是为后面做好准备工作，因为设计模式到处都离不开这些设计原则，如果说设计思想没有明确对错之分，那么在面向对象领域这六大设计原则就是底线，违反这些原则就谈不上是好的设计，相反如果遵循这六大原则，不一定严格按照某种设计模式，那么你的代码就是好代码了，好的代码不一定是严格按照设计模式写的代码。
单一职责原则（Single Responsibility Principle，简称SRP）
就一个类而言，应该仅有一个引起它变化的原因。通俗的说，即一个类只负责一项职责。这是一个备受争议却又及其重要的原则，因为单一职责的划分界限并不是总是那么清晰，很多时候都是需要靠个人经验来界定，如何划分一个类、一个函数的职责，每个人都有自己的看法，这需要根据个人经验、具体的业务逻辑而定。但是它也有一些基本的指导原则，例如两个完全不一样的功能就不应该放在一个类中。
开闭原则（Open Close Principle，简称OCP）
对扩展开放，对修改关闭。开闭原则是让程序更稳定、更灵活的一个基本保证。程序中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的，在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码。
接口隔离原则（InterfaceSegregation Principles，简称ISP）
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来，只有专注地为一个模块提供定制服务，才能建立最小的依赖关系，提高内聚，减少对外交互，使接口用最少的方法去完成最多的事情。接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化，所以一定要适度。
里氏替换原则（Liskov Substitution Principle，简称LSP）
所有引用基类的地方必须能透明地使用其子类的对象。面向对象的语言的三大特点是继承、封装、多态，里氏替换原则就是依赖于继承、多态这两大特性。里氏替换原则简单来说就是，所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是反过来就不行了，有子类出现的地方，父类未必就能适应。说了那么多，其实最终总结就两个字：抽象。
依赖倒置原则（Dependence Inversion Principle，简称DIP）
依赖反转原则指代了一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。这种表达真的让人很难理解，简单点：依赖倒置原则在 Java 语言中的表现就是：模块间通过接口依赖，实现类之间不发生直接的依赖关系。再简单点：面向接口编程，或者说是面向抽象编程
迪米特原则（Law of Demeter，简称LOD）
也称为最少知识原则（Least Knowledge Principle）：一个对象应该对其他对象有最少的了解，也就是关于如何松耦合，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
总结这几个原则你不用去背它，也不用尝试能够一次性完全理解它，等你后面吃过亏、犯过错或者重构过自己的代码，说不上哪一天这几个原则就会浮现在你的脑海里，你可以再回头重新理解一遍，到那时就可以恭喜你完成学习设计模式道路上的一个小循环。
原创首发于慕课网