版权声明：欢迎转载，转载请保留文章出处。 https://blog.csdn.net/junzia/article/details/78268333
程序开发中面向对象的一些相关的读书笔记。
面向对象概念相关
- 面向对象的三大特性：继承、封装和多态。继承，共性放到父类，特性放到子类。封装，对象有一个明确的边界，声明公开，实现隐藏，实现的更改，对对象的使用没有影响。多态，子类的对象可以放到父类的引用中，子类的方法可以覆盖父类的公有非final、或者protected方法。方法可以同名重载。每个对象都包含它能进行操作所需要的所有信息，这个特性称为封装，因此对象不必依赖其他对象来完成自己的操作。封装的好处如下：第一、良好的封装能够减少耦合。第二、类内部的实现可以自由修改。第三、类具有清晰的对外接口。如果对象A和B，可以描述为B是A，则表明B可以继承A。比如说男人是人，表明男人可以继承人。继承定义了类如何相互关联，共享特性。子类继承父类，则有：第一、子类拥有父类非private属性和功能。第二、子类具有自己的属性和功能，即子类可以扩展父类没有的属性和功能。第三、子类还可以以自己的方式实现父类的功能（方法重写）。继承是一种类与类之间的强耦合性。多态表示不同的对象可以执行相同的动作，但是要通过他们自己的实现来执行。多态特性如下：第一、子类可以以父类的身份出现。第二、子类在工作时以自己的方式来实现。第三、子类以父类的身份出现时，子类特有的属性和方法不可以使用。在C++中，为了使子类的实例完全接替来自父类的成员，父类必须将该方法声明为虚拟的，即在该成员的返回类型前增加virtual关键字。子类可以选择用override关键字，将父类的实现替换成它自己的实现，这就是方法重写。
- 面向对象设计的好处：可维护、可扩展、可复用、灵活性好。
- 面向对象的五大基本原则：SOLID，再加迪米特法则。
- 类之间的耦合越弱，越利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。
- 抽象类和接口的区别：第一、类是对对象的抽象，抽象类时对类的抽象，而接口是对行为的抽象。第二、如果行为跨越不同类的对象，可以用接口。对于一些相似的类对象，用继承抽象类。第三、从设计角度讲，抽象类是从子类中发现了公共的东西，泛化出父类，然后子类继承父类。而接口是根本不知道子类的存在，方法如何实现还不确定，预先定义。
面向对象类图UML图
- 类：三行，第一行为类名称，第二行为特性，即属性，第三行为操作，也就是方法。
- 接口：矩形表示法和类相似，但是在接口名上面会有<>标志。第一行为标志和接口名，第二行为接口方法。棒棒糖表示法，圆圈旁边为接口名称，接口方法出现在实现类中。
- 实现接口：一种是棒棒糖表示法，也就是圆圈+实线。另一种是空心三角形+虚线。
- 继承关系：用空心三角形+实线来表示。箭头指向继承类。
- 依赖关系：依赖关系用虚线箭头表示。比如A类的a方法，有B和C两个输入。那么A依赖B和C。
- 关联关系：关联关系用实线+箭头表示，当一个类需要知道另外一个类时，用关联关系表示。比如B中有字段A，那么就是B关联A，实线箭头由B指向A。
- 聚合关系：聚合关系用空心棱形+实线箭头表示。表示的是一种弱的拥有关系，体现的是A中可以包含B对象，但是B对象不是A对象的一部分。比如蜂群和单只蜂的关系。
- 合成关系：合成关系用实心棱形+实线箭头表示。表示的是一种强的拥有关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。比如鸟和它的翅膀的关系。
面向对象的基本原则
- 单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因。这是因为，如果一个类承担的职责太多，就是把这些职责都耦合到了一起，一个职责的变化可能会削弱或者控制这个类完成其他职责的能力，这种耦合会导致设置脆弱，当变化发生时，设计会遭到意想不到的破坏。
- 开放封闭原则（OCP）：软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。开放封闭原则是为了使设计面对需求的变化，可以保持相对的稳定，从而保证软件便于迭代。开放封闭需要预测最有可能发生的变化种类，然后构造抽象，来隔离这些变化。开放封闭式面向对象设计的核心所在，遵循这个原则
- 里式替换原则（LSP）：子类必须能够替换掉它的父类型，也是面向接口编程。就是说如果一个软件实体使用的是一个父类的话，那么一定适用其子类，而且它察觉不出父类对象和子类对象的区别，也就是说在软件里面，把父类都替换成它的子类，程序的行为应该是没有变化的。
- 接口隔离原则（ISP）：使用多个专门的接口，比使用单个接口好。接口隔离强调接口的单一性。
- 依赖倒转原则（DIP）：高层模块不应该依赖底层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。也就是说针对抽象编程，而不是针对细节编程。这和传统结构化编程的高层依赖底层模块想相反，所以叫依赖倒转。
- 迪米特法则（LoD）：又叫作最少知道原则，一个类应该对其他对象有最少的了解。如果两个类不必彼此直接同行，那么这两个类就不应该发生直接的相互作用，如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。迪米特法则强调的前提是在类的结构设计上，每一个类都应当降低成员的访问权限。迪米特法则的根本思想就是强调类之间的松耦合。
常用的设计模式
- 简单工厂模式：用一个单独的软件实体来做创建实体的过程，这就是工厂。工厂软件实体接受一个参数，通过不同的参数实例化不同的产品类。简单工厂模式最大的优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择调件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。这种方法是用户使用非常方便，用户不用管需要用那个类的实例，只需要给出参数，工厂就会为用户创建相应的实例。但是这会有另外一个问题，就是当用户的需求增加时，需要用到一个新类型的实例时，工厂的软件实体需要修改，这样就违背了开放封闭原则。
- 工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法针对每一种产品提供一个工厂类，通过不同的工厂实例来创建不同的产品实例。工厂方法使一个类的实例化延迟到其子类。由客户端决定需要实例化哪一个工厂，来实例化需要的实例，选择判断道德逻辑还是存在，只不过从工厂软件实体转移到了客户端。
- 抽象工厂模式：提供一个创建一系列相关或者相互依赖对象的接口，而无需指定它们具体的类。抽象工厂模式应用情景应当满足以下条件：系统中有多个产品族，而系统一次只能消费一个产品族。同属于一个产品族的产品一起使用，不同产品族的产品无需相互组合。抽象工厂是对于产品族的概念的。
- 策略模式：策略模式定义了算法家族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化，不会影响到使用算法的客户。策略模式的优点是简化了单元测试，因为每一个算法都有自己的类可以通过自己的接口单独测试。实际上，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能。
- 装饰模式：动态地给一个对象添加一些额外的职责，就增加来说，装饰模式比生成子类更加灵活。装饰模式可以有效的把类的核心职责和装饰功能区分开，而且可以去除相关类中重复的装饰逻辑。装饰模式，使实现一个对象和如何使用这个这个对象分离开了，每个装饰对象只关心自己的功能，而不需要关心如何被添加到对象链中。装饰模式是为已有功能动态添加更多功能的一种方式。
- 代理模式：为其他对象提供一种代理，以控制对这个对象的访问。代理模式分为四种，第一，远程代理，也就是为一个对象再不同的地址空间提供局部代表，这样可以隐藏一个对象存在于不同地址空间的事实。第二，虚拟代理，是根据需要创建开销很大的对象，通过它来存放实例化需要很长时间的真实对象。第三，安全代理，用来控制真实对象访问时的权限。第四，智能指引，是指调用真实的对象时，代理处理另外一些事。
- 原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式其实就是冲一个对象再创建另外一个可定制的对象，而且不需知道任何创建的细节。一般在初始化信息不发生变化的情况下，克隆是最好的办法。这既隐藏了帝乡创建的细节，又针对性能是大大的提高。
- 模板方法模式：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变是一个算法结构即可重定义该算法的某些特定步骤。
- 外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得子系统更加容易使用。外观模式完美的体现了依赖倒转原则和迪米特法则的思想。外观模式的使用分三个 阶段，在设计初期阶段，应该有意识的将不同的两个层次分离，层与层之间建立外观。其次，在开发阶段，子系统往往因为不断重构演化而变得越来越复杂，增加外观可以提供一个简单的接口，减少它们之间的依赖。另外，再维护一个遗留的大系统时，可能这个系统已经非常难以维护和扩展了，为新系统开发一个外观类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与外观对象交互，外观对象与遗留代码交互所有复杂的工作。
- 建造者模式：将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。它主要用于创建一些复杂的对象，这些对象内部构建间的建造顺序通常是稳定的，但内部的构建通常面临着复杂的变化。建造者的好处就是使得建造代码与表示代码分离，由于建造者影藏了该产品是如何组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时，可以考虑使用建造者模式。
- 观察者模式：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有的观察者对象，使它们能够自动更新自己。观察者模式所做的工作其实就是接触耦合 ，让耦合的双发都依赖于抽象，而不是依赖于具体，从而使得各自的变化都不会影响另一边的变化。当一个对象改变时，需要改变其他对象，而且它不知道具体有多少对象有待改变时，可以考虑用观察者模式。
- 状态模式：当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。状态模式的好处是将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。状态模式的目的是消除庞大的条件语句，通过把各种状态转移逻辑分布到状态类的子类之间，减少相互间的依赖。当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式。
- 适配器模式：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本不兼容而不能一起工作的那些类可以一起工作。当系统的数据和行为都正确，但是接口不符时，我们就应该考虑用适配器，目的是使控制范围之外的一个原有对象和某个接口匹配。适配器模式主要应用于希望复用的一些现存的类，但是接口又与复用环境要求不一致的情况。
- 备忘录模式：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将对象恢复到原先保存的状态。
- 组合模式：将对象组合成树形结构以表示部分-整体的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。当需求中是体现部分与整体层次的结构时，或者设计者希望用户可以忽略组合对象与单个对象的不同，统一的使用组合结构中所有的对象时，就应该考虑使用组合模式了。
- 迭代器模式：提供一种方法顺序的访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。当你需要访问一个聚集对象时，而且不管这些对象是什么都需要遍历的时候，就可以考虑使用迭代器模式。另外当需要对聚集对象有多种方式遍历时，可以考虑用迭代器模式。迭代器为遍历不同的聚集结构提供如开始、下一个、是否结束、当前哪一项等统一的接口。
- 单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点。我们可以用一个全局变量使得一个对象被访问，但是它不能防止你实例化多个对象。一个最好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。
- 桥接模式：将抽象部分和它的实现部分分离，使它们都可以独立的变化。这并不是说，让抽象类与其派生类分离，这里的实现指的是抽象类和它的派生类用来实现自己的对象。实现系统可能有多角度的分类，每一种分类都有可能变化，那么久把这种多角度分离出来让他们独立变化，减少他们之间的耦合。
- 命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化。对请求排队或者记录请求日志，以及支持可撤销的操作。它的好处是，第一，能够比较容易的设计一个命令队列。第二，在需要的情况下，可以容易地将命令记入日志。第三，允许接收请求的一方决定是否要否决请求。第四，可以容易地实现请求的撤销和重做。第五，由于新加的具体命令不影响其他操作，因此增加新的具体命令类很容易。命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。
- 责任链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这个对象连成一条链，并沿着这条链传递该请求，知道有一个对象处理它为止。职责链中的对象并不知道链的结构，这样职责链可简化对象的相互连接，他们仅需保持一个指向其后继承者的引用，从而不必保持它所有待选接受者的引用。客户端可以随时地增加或修改处理一个请求的结构，增强了给对象指派职责的灵活性。
- 中介者模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以 独立的改变他们之间的交互。中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分布在多个类中的行为而又不想生成太多子类的场合。
- 享元模式：运用共享技术有效的支持大量细粒度的对象。享元模式可以避免大量非常相似类的开销。在程序设计中，有时候需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本都是相同的，有时就能够大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面，在方法调用时将他们传递进来，就可以通过共享大幅度的减少单个实例的数目。
- 解释器模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。如果一种特定类型的问题发生大的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。用了解释器模式，就意味着可以很容易地改变和扩展文法，因为该模式使用类来表示文法规则，可以使用继承来改变或扩展该文法。以比较容易实现文法，因为定义抽象语法树种各个节点的类的实现大体相似，这些类都易于直接编写。但是，解释器模式为文法中的每一条规则至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。所以建议当文法非常长复杂时，使用其他技术如语法分析程序或编译器生成器来处理。
- 访问者模式：表示一个作用于某对象结构中的各个元素的操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。访问者模式增加新的操作很容易，因为增加一个新的操作就意味着增加一个新的访问者。访问者模式将有关行为集中到一个访问对象中。访问者模式增加新的数据结构比较困难。因此，访问者模式适用于数据结构相对稳定的系统。