对扩展开放，对修改关闭
解读:在生活中我们几乎不会想着往一个已经修好的高楼加一个地下室，但是在软件开发过程中，但凡有点研发经验的小伙伴们应该都有这有的经历，那就是在已经上线的代码中加入新的需求。当然这源于客户不断的更新自己的个性化需求。这个时候如何快速的满足当前的客户的个性化需求的同时不影响已有功能的正常运行成为了攻城狮们关心的主题。 这时开闭原则隆重的登上了面向对象设计的历史舞台。 在java中我们主要依赖 Java的三大特性之一的多态来实现，即通过重写父类方法的模式来达到扩展的目的。或者通过代理的方式实现扩展。
实现方式：重写父类方法、动态代理、静态代理。
分工明确，各司其职
解读：一个类只负责一件事。举个例子：一个人既当爹又当妈，也不是说不可以，只是我们在软件的设计的过程中极其不推介，因为当一个类负责一个以上的职责的时候，很有可能其中一个职责的修改会影响到另一个职责的功能。
实现方式：对象要尽可能的小。
你走你的阳关道、我过我的独木桥，我们进水不犯河水。
解读：接口中的方法要尽可能的少，职责尽可能单一（满足单一原则），因为如果接口的方法多了，这样当某个类实现这个接口的时候就会被迫的实现很多么有的方法。举个例子（还没想好形象的例子。。。TODO） Java是支持多实现的，所以接口尽可能小，需要这个功能的时候再去实现。这样设计的程序既有很好的扩展性，又降低了耦合。
实现方式：接口要尽可能的小，高扩展，低耦合。
设计的时候我们要依赖于抽象，而不是依赖于具体。
解读：这个原则其实适用于我们生活的方方面面，比如我们做一个发明，问题：发明一个可以带着东西和人快速前进的东西（交通工具）。我们在做这个发明的时候，应该依赖的是抽象（带人和东西 快速前进），那什么是具体呢（自行车），如果说我们依赖于自行车这个具体的交通工具，那么可能使个大劲最多也就发明个摩托，或者我们脑洞大一些，发明个轮椅。总而言之呢，依赖于个体做设计容易限制我们的思维。所以我们应该依赖于抽象，这样才有轿车 货车、飞机、动车、宇宙飞船的诞生。
实现方式：依赖于接口和抽象类做设计
干好自己分内的事情，竟可能少的了解别的对象
解读：在软件设计的时候虽然我们会尽可能的让设计满足单一原则，但是我们还是会经常有一些需求，需要在一个对象中用到别的对象的一些功能，这时候作为引用对象的一方应该尽可能少的了解被引用对象的内部实现，主要是为了避免个别人会修改被引用对象里面的属性或功能，在Java中类与类之间发生关系有这样几种方式：继承、实现、集成(一个类的内部引入另一类)。个人大力推介使用集成复用的方式。
实现方式：封装，组合复用
任何爹出现的地方随便换个儿子上去都可以搞定
解读：这个原则是对开闭原则的补充，简单的说就是子类可以继承父类，但是不能修改父类已有的功能。举个例子，我们有个抽象类Bird,里面有个普通方法fly() abstract class Bird{ void fly(){} }, 从设计原则的角度讲，每一个继承这个抽象类的子类都应该有飞的能力，但是有一天突然有个哥们写了个鸵鸟类：Ostrich 也继承了这个类，众所周知，鸵鸟是不会飞的，这样的话，在Bird出现的地方，要是放一个Ostrich上去，那大家都飞不起来了。系统中相关的功能就都不可用了。
实现方式：不能满足父类全部需求的时候不要去继承这个类
未完待续......
