(一)7种设计坏味道
1.僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。
2.脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
3.牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。
4.粘滞性: 做正确的事情比做错误的事情要困难。
5.复杂性(不必要的): 设计中包含有不具任何直接好处的基础结构。
6.重复性(不必要的): 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。
7.晦涩性: 很难阅读、理解。没有很好地表现出意图。
(二)11种原则 - Principle
----类原则
1.单一职责原则 - Single Responsibility Principle(SRP)
就一个类而言,应该仅有一个引起它变化的原因。
(职责即为“变化的原因”。)
2.开放-封闭原则 - Open Close Principle(OCP)
软件实体(类、模块、函数等)应该是可以扩展的,但是不可修改。
(对于扩展是开放的,对于更改是封闭的.
关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来.
开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象.
拒绝不成熟的抽象和抽象本身一样重要. )
3.里氏替换原则 - Liskov Substitution Principle(LSP)
子类型(subclass)必须能够替换掉它们的基类型(superclass)。
4.依赖倒置原则(IoCP) 或 依赖注入原则 - Dependence Inversion Principle(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
(Hollywood原则: "Don't call us, we'll call you".
程序中所有的依赖关系都应该终止于抽象类和接口。
针对接口而非实现编程。
任何变量都不应该持有一个指向具体类的指针或引用。
任何类都不应该从具体类派生。
任何方法都不应该覆写他的任何基类中的已经实现了的方法。)
5.接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。
接口属于客户,不属于它所在的类层次结构。
(多个面向特定用户的接口胜于一个通用接口。)
----包内聚原则
6.重用发布等价原则(REP)
重用的粒度就是发布的粒度。
7.共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。
一个变化若对一个包产生影响,
则将对该包中的所有类产生影响,
而对于其他的包不造成任何影响。
8.共同重用原则(CRP)
一个包中的所有类应该是共同重用的。
如果重用了包中的一个类,
那么就要重用包中的所有类。
(相互之间没有紧密联系的类不应该在同一个包中。)
----包耦合原则
9.无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
10.稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
应该把封装系统高层设计的软件(比如抽象类)放进稳定的包中,
不稳定的包中应该只包含那些很可能会改变的软件(比如具体类)。
11.稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。
(一个稳定的包应该也是抽象的,一个不稳定的包应该是抽象的. )
----其它扩展原则----
12.BBP(Black Box Principle)黑盒原则
多用类的聚合,少用类的继承。
13.DAP(Default Abstraction Principle)缺省抽象原则
在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作.
14.IDP(Interface Design Principle)接口设计原则
规划一个接口而不是实现一个接口。
15.DCSP(Don't Concrete Supperclass Principle)不要构造具体的超类原则
避免维护具体的超类。
16.迪米特法则
一个类只依赖其触手可得的类。
(三)23种设计模式 - Pattern.
创建型
Abstract Factory(抽象工厂模式) -> (简单工厂模式)
Factory Method(工厂模式)
Builder(生成器模式)
Singleton(单件模式) -> (多例模式)
Prototype(原型模式)
结构型
Adapter(适配器模式)
Bridge(桥接模式)
Composite(组合模式)
Decorator(装饰模式)
Facade(外观模式,门面模式)
Flyweight(享元模式) -> (不变模式)
Proxy(代理模式)
行为型
Chain of Responsibility(职责链模式)
Command(命令模式)
Interpreter(解释器模式)
Iteartor(迭代器模式)
Mediator(中介者模式)
Memento(备忘录模式)
Observer(观察者模式)
State(状态模式)
Strategy(策略模式)
TemplateMethod(模板方法模式)
Visitor(访问者模式)
分享到:
相关推荐
标题“代码坏味道整理”指的是在编程过程中,代码可能会出现的一些不良习惯或低效的编程实践,这些被称为“代码坏味道”。这些坏味道通常会使代码难以理解、维护和扩展,降低了软件的质量。为了提高代码可读性和可...
在第三章中,作者详细列举了多种"代码的坏味道",也就是代码中常见的问题和反模式,旨在帮助开发者识别这些问题并进行有效的重构。 "源码"标签表明我们将关注代码的实际结构和质量,而"工具"标签则暗示可能涉及到...
重构,正如标题所言,包括了“重构介绍”、“重构原则”以及“代码的坏味道”等多个方面,旨在提高代码的可读性、可维护性和整体质量。 首先,我们来探讨“重构介绍”。重构是一种系统性的修改现有代码的过程,目的...
### 《重构 改善既有代码的设计》之代码的坏味道 #### 代码的坏味道简介 重构是一种改进代码质量的重要手段,它不仅能够提升代码的可读性和可维护性,还能帮助开发者更好地理解现有系统架构。《重构 改善既有代码...
**代码的坏味道与重构方式对应表** 代码的坏味道是指在编程过程中可能出现的不良编程习惯,这些习惯可能导致代码难以理解和维护。以下是一些常见的代码坏味道及其对应的重构方法: 1. **重复代码 (DRY - Don't ...
以下是我近期在代码审查中注意到的五种出现次数较多的代码坏味道,并针对每一种提供了解决建议。 1. 过大的类:遵循“单一职责原则”是编写可维护代码的关键。当一个类承担了过多的职责,变得过大时,就违反了这个...
2-10 构建者模式的实用工程技术——代码的坏味道:算法与对象构建的隔离 2-11 原型模式的定义场景与实现——对象的快速复制 2-12 原型模式的实用工程技术——DRY原则与使用模式进行重构 3-1 适配器模式的定义、场景...
1. **重构的动机**:重构的主要目标是消除代码中的坏味道,如过长的方法、重复的代码、复杂的条件语句等,以提升代码质量,降低维护成本。 2. **重构的原则**:遵循小步前进的原则,每次重构只做一小部分改动,并...
书中详细介绍了各种重构技术,如何识别坏味道的代码并改进,以及何时进行重构以提高代码质量。 5. **团队协作与沟通**:敏捷开发强调团队间的紧密协作和高效沟通。书中探讨了站立会议、每日同步、跨职能团队等实践...
书中提出了许多重构技术,如提取方法、移动函数、替换条件语句为策略等,这些技术有助于消除代码中的坏味道,保持代码的整洁。 重构时,单元测试起着至关重要的作用。通过编写测试,开发者可以在重构过程中确保代码...
2. **重构的步骤和技巧**:学习一系列实用的重构手法,包括如何识别代码坏味道,以及如何逐步改进代码结构。 3. **设计模式的解析**:理解各种经典设计模式的原理、适用场景及其在重构过程中的应用。 4. **实例分析*...
它通过消除代码中的坏味道,如冗余代码、过长函数、复杂的条件逻辑等,使代码更易于理解和维护。重构的主要目的是提升代码的可读性,降低未来修改和扩展的难度。 1. **何时进行重构** - 当发现代码难以理解时。 -...
设计中可能出现的“坏味道”包括: - **僵化性**:系统难以适应变化。 - **脆弱性**:小改动可能引发大问题。 - **牢固性**:过度耦合,修改一处可能需要全面审查。 - **晦涩性**:代码难以理解和维护。 - **粘滞性...
书中介绍了23种经典设计模式,虽然篇幅不长,但由于其理论性强,对于初学者可能较为晦涩。如果你已具备一定的基础,这本书将提供深入理解设计模式的宝贵资源。 2. **《Head First 设计模式》**:与GoF的《设计模式...
- **重构**:对检测到的代码坏味道进行重构,遵循 SOLID 原则。 - **模块化**:将大型类或方法拆分为更小、更专注的组件。 - **简化条件逻辑**:减少复杂的 if-else 结构,使用 case 或者 switch 语句替代。 - **...
2. 识别坏味道的代码:书中可能会列出一些代码的“坏味道”,如重复代码、过长函数、过大的类等,这些都是需要重构的信号。 3. 重构技术与步骤:详细解释各种重构手法,如提取方法、提取类、引入参数对象等,并指导...
重构是软件开发过程中的一个重要环节,它关注于改善代码的结构和设计,使之更易于维护和...以上是针对代码坏味道和重构方法的详细分析,通过这些重构和模式的应用,可以显著提升代码质量,使得软件更加健壮和易于维护。