对扩展开放,对修改关闭。
在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。简言之,是为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类。
子类型必须能够替换掉它们的父类型。由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。
面向对象设计的基本原则之一。
里氏代换原则中说, 任何基类可以出现的地方,子类一定可以出现。 LSP 是继承复用的基石,只有当派生类可以替换掉基类,且软件单位的功能不受到影响时,基类才能真正被复用,而派生类也能够在基类的基础上增加新的行为。
里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化,而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。
高层模块不应该依赖低层模块,两个都应该依赖抽象;抽象不应该依赖细节,细节应该依赖抽象。
要针对接口编程,不要针对实现编程。该原则可以说是面向对象设计的标志,编写时考虑的是如何对抽象编程而不是针对细节编程,即程序中所有的依赖关系都是终止于抽象类或者接口。
使用多个隔离的接口,比使用单个接口要好。从而降低类之间的耦合度。
针对类是 “单一职责原则” :就一个类而言,应该仅有一个引起它变化的原因。
一个实体应当尽量少地与其他实体之间发生相互作用,使得系统功能模块相对独立。
该原则其根本思想,是强调了类之间的松耦合;类之间的耦合越弱,越利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成波及。在类的结构设计上,每一个类都应当尽量降低成员的访问权限。
尽量使用合成/聚合的方式,而不是使用继承。
聚合表示一种弱的“拥有”关系,体现的是A对象可以包含B对象,但B对象不是A对象的一部分;
合成则是一种强的“拥有”关系,体现了严格的部分和整体的关系,部分和整体的生命周期一样。
优先使用对象的合成/聚合将有助于你保持每个类被封装,并被击中在单个任务上,这样类和类继承层次会保持较小规模,并且不太可能增长为不可控制的庞然大物。
它使一个类知道另一个类的属性和方法(成员变量);
关联可以是双向的(老师与学生),也可以是单向的(学生与课程)。
双向:两个箭头或者没有箭头;
单向:指向被拥有者。
是关联关系的一种,是强的关联关系;部分可以离开整体而单独存在。
是关联关系的一种,是比聚合关系还要强的关系;部分不能离开整体而单独存在,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。例如:没有公司就不存在部门。
一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖。
例如:局部变量、方法的参数或者对静态方法的调用;
泛化(继承) = 实现(类与接口) > 组合(整体与部分,部分不能离开整体) > 聚合(整体与部分,部分可以离开整体) > 关联(拥有) > 依赖(使用)
应用场景:
应用场景:
假如你有一个几何形状类:圆形、方形 。扩展颜色:红色、蓝色。 需要创建四个类才能覆盖所有组合。
如果应用的核心模型能用树状结构表示, 在应用中使用组合模式才有价值。
应用场景:
假如你有两类对象: 产品、盒子 。 盒子又包含:多个产品或者几个较小的盒子。小盒子同样又包含一些产品或更小的盒子,以此类推。
应用场景:
觉得冷时, 你可以穿一件毛衣。 如果还冷, 你可以再套上一件夹克。 如果遇到下雨, 你还可以再穿一件雨衣。 所有这些衣物都 “扩展” 了你的基本行为, 但它们并不是你的一部分, 如果你不再需要某件衣物, 可以方便地随时脱掉。
应用场景:
仅在程序必须支持 大量对象 且 没有足够的内存 容量时使用享元模式。对象中 包含可抽取且能在多个对象间共享的重复状态。
应用场景:
射击游戏中, 多个数组成员变量来存储每个粒子(子弹)的坐标、 方向矢量和速度。另一个数组来存储指向代表粒子的特定享元的引用。 这些数组必须保持同步, 这样你才能够使用同一索引来获取关于某个粒子的所有数据。
结构:
应用场景:
应用场景:
应用场景:
餐厅点餐, 服务员记下你点的食物, 写在一张纸上(订单),并送给厨师,厨师做好后。 服务员检查后将食物放到了你的桌上。
那张纸就是一个命令, 它在厨师开始烹饪前一直位于队列中。 命令中包含与烹饪这些食物相关的所有信息。 厨师能够根据它马上开始烹饪, 而无需跑来直接和你确认订单详情。
应用场景:
应用场景:
应用场景:
应用场景:
应用场景:
应用场景:
应用场景:
应用场景: