设计模式之禅精述

     在9月初花费20天左右的时间看完《细说PHP》后，稍作感慨开始《设计模式之禅》的阅读，坚信读万卷书行万里路，这里作读后记录和小结；

前言

     在之前看过的不少相关编程类的书籍，几乎都会把软件设计和建筑工程做比较，然后就是从建筑的底层地基讲到高层建筑的顺序和其中的一些概念来类比软件设计。这样子的话，我觉得设计模式是和建筑能否能够经受住时代审美的考验（拥抱变化–也是最基本的设计原则（开闭原则的初衷））有关联的。
      聪明的人，把房子盖在磐石上；无知的人把房子盖在沙土上；而对于开发者而言，设计模式就是坚固的顽石； -----Java开发者社区
     目录：

• 设计模式之禅总述
• 设计模式之禅–六大设计原则–单一职责原则
• 设计模式之禅–六大设计原则–里氏替换原则

     **

一、设计模式之禅总述

**
      禅是佛家用语，有‘参禅’，‘悟禅’等说法，像是一些高深莫测、深奥的道理；而设计模式之禅，我理解中，一是设计模式本来就是行业前辈总结、归纳出来的优秀、高深、值得人深思的设计指导思想，智慧结晶；二是学习设计模式需要像参禅悟道一样，静心思考，学以致用，因为世界上最难的事情有两种：一是让人心甘情愿的把钱掏出来给你；二是把自己的思想灌输的别人的脑袋里。
      设计模式是为了拥抱变化，总结出来的一套设计模式：分为六大设计原则，和二十三种设计模式；六大设计原则是由开闭原则衍生，通过不同方向的抽象而形成，也是设计模式的指导思想；二十三中设计模式则是在不同情景下的设计实现方式；
     问题来了，为什么是拥抱变化而归结的呢？
      在一个产品的生命周期中，遇到变化是不可避免的，而适当的拥抱变化，会整体提高系统的稳定性、灵活性；
      **

二、设计模式之禅–六大设计原则–单一职责原则

**
     单一职责设计原则指，一个接口或者类只有一个原因引起变化；即尽可能的使类、接口功能单一化，在提高代码重用性、可读性、可维护性、可扩展性的同时，减少类或接口的复杂度，变化到来时的开发工作量。
     举个栗子，一个类中记录了原始人的语言、居住地信息，此类的每个实例代表了一个原始人；
     随着时间的变迁，语言、居住信息可能其中一个或两个都发生了变化，那么此时用之前的类实例代表每个人就不准确。
     方案对比：如果坚持之前类的话，生成实例时针对每种情况都要改动语言、和居住信息的源码；包括生成实例的场景代码；如果采用语言和居住信心分别对应抽象类或者接口的话，只需增加每种语言和居住信息的实体类或方法，之后在每次生成实例时，只需要调用合适的实体或方法即可。
     注意：在进行职责单一化的过程中，可能会出现类之间的耦合度增高的情形，这里可以通过实现多个接口进行解耦操作；
     **

三、设计模式之禅–六大设计原则–里氏替换原则

**
     里氏替换原则指，只要父类出现的地方子类就可以出现，而且替换为子类也能正常执行；
     这里呢，抛出几个学习中的问题：
      抽象类是否可以实例化?
      Java和PHP中的抽象类、接口是否有区别？
     是否能够通过判断拥有方法体来区分抽象类、接口？
      类之间的委派机制是指什么？
     对象的上下转型中，为什么向下转型会抛出异常？
           DWSL接口是指什么？
      为什么要求父类的前置条件较大？
答案待续