本文详细探讨了面向对象设计的七大原则，特别是里氏替换原则，通过实例说明其实质和应用。此外，深入解析了创建者模式，包括其定义、意图和在软件设计中的作用。最后介绍了设计模式的概览和分类，重点讲解了创建者模式的组成部分和应用场景。
目 录
1. 面向对象七大设计原则
①开闭原则
②里氏替换原则
③单一职责原则
④接口隔离原则
⑤依赖倒置原则
⑥迪米特原则
⑦组合/聚合复用原则
①开闭原则
它的含义是对扩展开放，对修改关闭。
我的理解：我们写完的代码，不能因为需求变化就修改。我们可以通过新增代码的方式来解决变化的需求。当然，这是一种理想的状态，在现实中，我们要尽量的缩小这种修改。
开闭原则除了可扩展性强以外，还可以降低维护成本。所以，开闭原则是设计模式的第一大原则，它的潜台词是：控制需求变动风险，缩小维护成本。
其他几种原则，都是为此原则服务的。
②里氏替换原则
此原则的含义是子类可以在任何地方替换它的父类。解释一下，这是多态的前提，我后面很多所谓的灵活，都是不改变声明类型的情况下，改变实例化类来完成的需求变更。当然，继承的特性看似天然就满足这个条件。但这里更注重的是继承的应用问题，我们必须证我们的子类和父类划分是精准的。
里氏换原则的潜台词是：尽量使用精准的抽象类或者接口。
③单一职责原则
单一职责的含义是：类的职责单一，引起类变化的原因单一。
如果我们把类拆分成最小的职能单位，那组合与复用就简单的多了，如果一个类做的事情太多，在组合的时候，必然会产生不必要的方法出现。
单一职责的潜台词是：拆分到最小单位，解决复用和组合问题
④依赖倒置原则
依赖倒置原则就是要求调用者和被调用者都依赖抽象，这样两者没有直接的关联和接触，在变动的时候，一方的变动不会影响另一方的变动。
依赖倒置的潜台词是：面向抽象编程，解耦调用和被调用者。
⑤接口隔离原则
接口隔离原则可以说是单一职责的必要手段，它的含义是尽量使用职能单一的接口，而不使用职能复杂、全面的接口。很好理解，接口是为了让子类实现的，如果子类想达到职能单一，那么接口也必须满足职能单相反，如果接口融合了多个不相关的方法，那它的子类就被迫要实现所有方法，尽管有些方法是根本用不到的。这就是接口污染。
接口隔离原则的潜台词是：拆分，从接口开始
⑥迪米特原则
迪米特原则要求尽量的封装，尽量的独立，尽量的使用低级别的访问修饰符。这是封装特性的典型体现。一个类如果暴露太多私用的方法和字段，会让调用者很茫然。并且会给类造成不必要的判断代码。所以，我们使用尽量低的访问修饰符，让外界不知道我们的内部。这也是面向对象的基本思路。这是迪米特原则的一个特性，无法了解类更多的私有信息。
另外，迪米特原则要求类之间的直接联系尽量的少，两个类的访问，通过第三个中介类
来实现。
迪米特原则的潜台词是：不和陌生人说话，有事去中介
⑦组合聚合复用原则
此原则的含义是，如果只是达到代码复用的日的，尽量使用组合与聚合，而不是继承。
这里需要解释一下，组合聚合只是引用其他的类的方法，而不会受引用的类的继承而改变血
统。
继承的耦合性史大，比如一个父类后来添加实现一个接口或者去掉一个接口，那子类能会遭到毁灭性的編译错误，但如果只是组合聚合，只是引用类的方法，就不会有这种巨大
的风险，同时也实现了复用。
组合聚合复用原则的潜台词是：我只是用你的方法，我们不一定是同类。
2. 里式替换原则详解
①里氏替换原则概念
里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了父类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。
②里氏替换原则的主要作用
里氏替换原则是实现开闭原则的重要方式之一。
它克服了继承中重写父类造成的可复用性变差的缺点。
它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。
加强程序的健壮性，同时变更时可以做到非常好的兼容性，提高程序的维护性、可扩展性，降低需求变更时引入的风险。
我的理解：
里氏代换原则的意思并不是“子类不能重写父类的方法”，而是“子类重写父类方法时，可以改变方法的具体行为，但不应该改变方法的用途”。比如父类有一个排序功能，子类可以重写来改变排序的算法，但不应该改变排序这个功能，这样父类才可以被子类替换。
③错误实例
几维鸟类图
实例分析：
鸟一般都会飞行，但是新西兰的几维鸟由于翅膀退化无法飞行。
如果几维鸟类重写了鸟类的 setSpeed(double speed) 方法，就违背了里氏替换原则。
拿燕子来测试，结果正确，程序正常；但拿几维鸟来测试，结果会发生“除零异常”或是“无穷大”。
④正确实例
几维鸟类图
实例分析：
应该取消几维鸟原来的继承关系，定义鸟和几维鸟的更一般的父类，如动物类，它们都有奔跑的能力。几维鸟的飞行速度虽然为 0，但奔跑速度不为 0。
3. 设计模式
①设计模式概念
设计模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。我们可以用设计模式解决重复遇到的问题，节省时间或者优化解决方案。
②一个模式有四个基本要素
1. 模式名称一个助记名，它用一两个词来描述模式的问题、解决方案和效果。
2. 问题描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。
3. 解决方案描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
4. 效果描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。
③设计模式的分类
总体来说设计模式分为三大类：
创建型模式(共五种)：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式(共七种)：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式(共十一种)：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
4. 创建者模式详解
①定义
创建者模式(Builder Pattern)使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，一种创建对象的最佳方式之一，该模式将对象表示与构建过程分离，实现解耦，并且保证了复杂对象(对象的属性也是对象)创建的正确性。
一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。
②意图
将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
③主要解决的问题
主要解决在软件系统中，有时候面临着"一个复杂对象"的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。将变与不变分离开。
④优点
1. 建造者独立，易扩展。
2. 便于控制细节风险。
⑤缺点
1. 产品必须有共同点，范围有限制。
2. 如内部变化复杂，会有很多的建造类。
⑥使用场景
1. 需要生成的对象具有复杂的内部结构。
2. 需要生成的对象内部属性本身相互依赖。
一些基本部件不会变，而其组合经常变化的时候。
区别：与工厂模式的区别是——创建者模式更加关注与零件装配的顺序。
⑦建造者模式的主要角色
产品角色(Product)：它是包含多个组成部件的复杂对象和属性，是一个模型。
抽象建造者(Builder)：它是一个包含创建产品各个子部件的抽象方法的接口或者抽象类，通常还包含一个返回复杂产品的方法 ，该方法一般是抽象并且返回值类型是产品角色（Product）。
具体建造者(Concrete Builder)：实现 Builder 接口或者继承Builder 抽象类，完成复杂产品的各个部件的具体创建方法。
指挥者(Director)：它调用建造者（Builder）中的部件构造与装配方法完成复杂对象的创建，不设计产品具体构建细节。
⑧实例
创建不同种类的汽车与不同种类的汽车手册
实例解释：
1、实体类：Car(汽车)，Manual(汽车手册)，这两个就是实例所要创建的最终对象。
2、抽象建造者和具体建造者：
Builder：抽象建造者，是一个抽象建造接口，定义了建造一个车/手册的所有流程方法。
CarBuilder：汽车具体建造者，内部提供一个getResult()方法获取一个Car对象。
CarManualBuilder：汽车手册具体建造者，具体的手册建造者，内部提供一个getResult()方法获取一个Manual对象。
3、指挥者：Director类，对传入的建造者进行赋值，从而创建出不同的car对象和Manual对象。
扫一扫
3251
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
