qq_36620683的博客

创建型 单例模式 名词解释 全局只包含一个对象。 使用场景 编码实现 工厂模式 建造者模式 原型模式 结构型 代理模式 桥接模式 装饰器模式 适配器模式 门面模式 组合模式 享元模式 行为型 观察者模式 模板模式 策略模式 职责链模式 迭代器模式 状态模式 访问者模式 备忘录模式 命令模式 解释器模式 中介模式 ...

文章目录面向对象面向对象四大特性面向对象分析、设计与编程基于接口而非实现编程多用组合少用继承贫血模型 VS 充血模型设计原则SOLID原则KISS、YAGNI原则DRY原则LOD 迪米特法则编码规范重构技巧在程序中加入单元测试编写可测试的代码大型重构和小型重构小型重构：编码规范 面向对象 面向对象四大特性 封装、抽象、继承、多态 面向对象分析、设计与编程 OOA 输入是模糊的需求，输出是流程化的明确的需求 OOP 输入是流程化的需求，输出是具体的类和类关系 基于接口而非实现编程 多用组合少用继承 贫

KISS Keep It Short and Simple. DRY Don’t Repeat Yourself LOD Law of Demeter LOD 迪米特法则 不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”） 关于高内聚，低耦合 “高内聚、松耦合”是一个非常重要的设计思想，能够有效提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。“高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间依赖关系的设计。 所谓高内.

S Single Responsibility Principle O Open Closed Principle L Liskov Substitution Principle I Interface Segregation Principle D Dependency Inversion Principle 单一职责原则 一个类或者模块只负责完成一个职责（或者功能） 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分； 类依赖的其他类过多，或者依赖类的其.

OOA OOD OOP 当我们接到一个模糊或者具体的需求，一个通用的流程范式是 需求分析 -> 方案设计 -> 编码实现 需求分析 面向对象分析的输入是一个模糊或者具体的需求 ，产出是详细的需求描述。 需求分析是一个反复迭代才能出现“结果宝石”的过程，就像解一道算法题一样：有一个最初的实行方案，然后发现问题，解决问题或推翻设想重来。 - 举个例子：需求是服务端要添加一个鉴权功能 - 最开始考虑使用用户名口令鉴别身份 - 发现明文容易被中间人抓包获取所以传输时使用hash后的密.

什么是贫血模型？ 什么是充血模型？ 为什么说基于贫血模型的传统开发模式违反 OOP? 基于贫血模型的传统开发模式既然违反 OOP，那又为什么如此流行？ 什么情况下我们应该考虑使用基于充血模型的 DDD 开发模式？ 什么是贫血模型？ 贫血模型（Anemic Domain Model）是指开发过程中业务的具体方法不在对应的子业务中实现。 以MVC举例。当前后端分离时，后端大致结构为RSC： Repository层，用于在和数据库，中间键等交互，属性定义在Entity中，方法实现在Repository。 Mo.

自生成方法 众所周知，C++类有四种函数如果不显示定义会自动生成：构造函数、析构函数、拷贝构造函数、运算符重载(operator = )。在继承时，很多特殊情况也就出在这四类函数中。 继承中派生类内包含了基类内所有方法和属性，只是由于private 权限修饰不能在派生类中直接调用而已。但是基类构造函数明明就算设置成public,在子类对象中也是不能直接使用的。这其实就很容易理解：基类和派生类的构造、析构、拷贝构造甚至都不重名，运算符重载参数也一般直接指定的本对象的类型(如果想直接使用父类的运算符重载函数，不

c++ 面向对象之封装、抽象、继承、多态 最近正在学习设计模式，所以总结一下c++为面向对象提供的一些语言特性。作为涉及模式这个专栏的开篇。 封装 封装其实很容易理解，就是使用类(class)将很多属性封装起来。值得注意的是 三种访问权限 public:可以类创建的实体访问 protected:只允许子类及本类的成员函数访问 private:只允许本类的成员函数访问 三种继承方式 public 继承 protected 继承 private 继承 基类中 继承方式 子类中 p