7 处理继承关系
7 处理继承关系1 Pull Up Field(字段上移)如果两个子类有相同的字段,则将该字段上移至超类中。 2 Pull Up Method(函数上移)如果两个子类有相同的函数而且产生完全相同的结果,则将该函数上移至超类。 3 Extract Superclass(提炼超类)如果两个类有相似特性,可以为这两个类建立一个超类,将相同特性移至超类。如果继承不合适,可以使用[Extract Class](#Extract Class)来提取重复代码。 4 Form Template Method(塑造模板函数)该重构的手法其实就是设计模式中的模板模式,如果有一些子类,其中对应的某些函数以相同顺序执行类似的操作,但在各个操作的细节上有所不同。可以将这些操作分别放到独立的函数中,替换在原函数中原有的操作代码,并上移至超类。 重构示例2212345678910111213141516171819202122232425262728// 重构前class Site {public: virtual double GetBillableAmount() = 0; /...
附录1 代码重构理论
重构 参考文献 https://www.cnblogs.com/ranjiewen/p/5912259.html https://blog.csdn.net/ruanrunxue/article/details/102945431 1 什么是重构?重构的定义Martin Fowler在《重构:改善既有代码的设计》一书中给出了重构的两个定义. 第一个是名词形式:Refactoring: 对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本. 第二个是动词形式:Refactor: 使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构. 重构的目标重构的目标是什么? 重构的目标绝不是将代码从别人的taste改成自己的taste,也不是将代码从一种坏味道改到另一种坏味道!Matin Fowler利用上面两个定义,指出了重构的目标: 不改变软件可观察行为 提高软件可理解性 降低软件修改成本 而对于上述目标,我们再深入一点分析,发现其实已经有更经典的定义. 那就是Kent Beck的简单设计四原则: Pass All Tes...
6 简化函数调用
6 简化函数调用1 Introduce Parameter Object(引入参数对象)在代码中,可能有一组参数总是一起被传递到好几个函数中,这样的一组参数就是所谓的Data Clumps(数据泥团)。最常见的就是指代一个时间范围的startTime/endTime。可以通过Introduce Parameter Object手法,以一个对象取代这些参数。 重构示例19123456789101112131415// 重构前class Account {public: double GetFlowBetween(Date& startTime, Date& endTime) { double result = 0.0; for (auto& entry : m_entries) { if (entry.GetDate() == startTime || entry.GetDate() == endTime || (entry.G...
附录3 重构规划书
SimuRosot项目重构规划书1 重构的目标 增强可读性(自动生成项目的说明文档) 增强可扩展性,降低模块的耦合和代码的冗余。面向对象、接口。 增强可修改性,方便代码进行修改和扩展。 2 重构的流程 重读设计模式和架构设计。使用更好的架构和模块设计方案。(给出一个架构设计说明书)。 了解重构工具和重构的方法。熟练掌握C++项目重构过程。 cmake/vs 项目重构。使用了解。 熟读源代码,对架构设计说明书进行增删修改。完成最终的架构设计说明书。 使用vs对项目架构进行重构。 添加测试模块用来对策略和函数效果评估。 方案1:主要还是重新设计项目,把项目内的其他代码赋值黏贴出来。让它成为一个新的能够运行的小项目。 方案2:重新设计项目,然后在原有的代码上进行重构。 3 重构的原则 分层设计。上层对下层依赖。层内部不允许依赖。 控制反转。使用register机制,将对象注册到core中,计算执行。 决策树。减少strategy过程中if-else的逻辑。 高内聚低耦合。减少类之间的依赖,增强类内部的函数依赖。 文档生成与规范化。 运行时数据依赖与静态数据...
1.1 单一职责原则
单一职责原则(Single Responsibility Principle) 1 单一职责原则 (SRP:The Single Responsibility Principle) 为什么 因为每一个职责都是一个变化的中心。当需求变化时,这个变化将通过更改职责相关的类来体现。 如果一个类拥有多于一个的职责,则这些职责就耦合到在了一起,那么就会有多于一个原因来导致这个类的变化。对于某一职责的更改可能会损害类满足其他耦合职责的能力。这样职责的耦合会导致设计的脆弱,以至于当职责发生更改时产生无法预期的破坏。 低耦合高内聚 是什么 一个类应该有且只有一个变化的原因。 There should never be more than one reason for a class to change. 2 实例 例如,考虑下图中的设计。类图中显示 Rectangle 类包含两个方法,一个方法(Draw)负责在显示屏幕上绘制矩形,另一个方法(Area)负责计算矩形图形面积。 有两个不同的应用程序均使用了 Rectangle 类。一个应用为计算几何程序,它使用了 Rectangl...
0 设计模式之美
设计模式之美 我发下所有的代码层面、软件层面、系统层面、多个系统组成的微服务层面… …这些不同粒度的实体,都遵循相同的设计模式。太美了,后续重新学习一下各个模式(看个视频数遍复习笔记) 参考文献 https://www.cnblogs.com/gaochundong/tag/Design%20Pattern/ 目录 设计模式分类 设计模式之间的关系 设计模式所支持的设计的可变方面 设计模式怎样解决设计问题 1 设计模式分类 目的 (Purpose) 创建型 (Creational) 结构型 (Structural) ...
1.2 开放封闭原则
1 开放封闭原则 OCP(Open Closed Principle) 为什么 “所有系统在其生命周期中都会进行变化,只要系统要开发一个版本以上这一点就需时刻记住。” All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version. 在面向对象的设计中有很多流行的思想,比如说 “所有的成员变量都应该设置为私有(Private)” “要避免使用全局变量(Global Variables)” “使用运行时类型识别(RTTI:Run Time Type Identification,例如dynamic_cast)是危险的” 那么,这些思想的源泉是什么?为什么它们要这样定义?这些思想总是正确的吗?本篇文章将介绍这些思想的基础:开放封闭原则(Open Closed Principle)。 那么我们到底如何才能构建一个稳定的设计来面对这些变化,以使软件生命周期持...
1.3 里氏替换原则
1 里氏替换原则(Liskov Substitution Principle)为什么开放封闭原则(Open Closed Principle)是构建可维护性和可重用性代码的基础。它强调设计良好的代码可以不通过修改而扩展,新的功能通过添加新的代码来实现,而不需要更改已有的可工作的代码。抽象(Abstraction)和多态(Polymorphism)是实现这一原则的主要机制,而继承(Inheritance)则是实现抽象和多态的主要方法。 那么是什么设计规则在保证对继承的使用呢?优秀的继承层级设计都有哪些特征呢?是什么在诱使我们构建了不符合开放封闭原则的层级结构呢?这些就是本篇文章将要回答的问题。 是什么 里氏替换原则:所有引用基类的地方必须能透明地使用其子类的对象。使用基类对象指针或引用的函数必须能够在不了解衍生类的条件下使用衍生类的对象。 Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing ...














