面向对象

面向对象是一种思想，就是搞得好理解一点，一个方向一个方向的去理解，分开几块，每块又把一类事聚到一起

crc卡片分拣法：
CRC卡片包括三个部分：类名、类的职责、类的协作关系，每一张卡片表示一个类。
大概就是，给类分配职责，协作关系的话，是很正重要的，所以用个卡牌，就便于思考了。

接口啊，就是一种标准，实现类去具体实现它，本质上做一样的事，实际上，做法并不一样，
这玩意设计要遵循很多原则，比方说什么里式替换啊，开放封闭啊，依赖倒置啊，接口分离啊，我也不太懂…

类图就是把类画出来，考虑错综复杂的关系，画画框画画线

一、单一职责原则（ＳＲＰ）         就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。        二、开闭原则（ＯＣＰ）        软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它 的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。 该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。        三、替换原则（ＬＳＰ）        子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。        四、依赖倒置原则（ＤＩＰ） １、 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。２、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该 尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层 的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影 响高层抽象的模块，显然这是结构化方法的一个"硬伤"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。 五、接口分离原则（ＩＳＰ） 采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。  ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。