1. DRY
DRY,全称 Don't Repeat Yourself(不要重复你自己),它是软件开发中的一个重要设计原则,旨在减少代码的重复性,提高代码的可维护性和可读性。遵循 DRY 原则可以使代码更加简洁、易于理解和修改。
(1) DRY 核心思想
DRY 的核心思想是:任何知识在系统中都应该有一个单一、明确、权威的表示,简单来说,就是避免在代码中出现重复的逻辑或数据。
(2) 如何实现 DRY?
①抽象和封装
- 将重复的代码抽象为函数、方法或者类。
- 使用模块化编程,将常用的逻辑封装在独立的模块中,便于复用。
②使用常量
- 如果某个值在代码中多次使用,可以将其定义为常量,避免硬编码。
- 这样不仅减少了重复代码,还提高了代码的可读性和可维护性。
③利用继承和多态
- 在面向对象编程中,使用继承和多态来减少代码重复。
- 将通用的功能放在父类中,子类继承并扩展这些功能。
④模板和泛型
- 使用模板和泛型来创建可重复使用的代码结构,适用于多种类型和场景。
⑤配置文件和数据库
- 将可变的数据和配置项存储在配置文件或数据库中,而不是硬编码在程序中。
(3) DRY 的优势
①提高代码质量
- 避免代码重复,使代码更加简洁和易于理解。
- 减少了出错的可能性,因为同一个逻辑只需要维护一处。
②便于维护
- 代码修改时只需更改一个地方,减少了维护成本。
- 提高了代码的一致性和可靠性。
③增强代码复用性
- 通过抽象和封装,提高了代码的复用性,减少了重复工作。
2. KISS
KISS,全称 Keep It Simple And Stupid(保持简简单),旨在提醒开发人员尽量保持代码的简洁性和易读性。
(1) KISS 核心思想
KISS原则的核心思想是尽量避免不必要的复杂性。这意味着在设计和编写代码时,应尽量选择简单、直接的解决方案,而不是过度设计或引入不必要的复杂性。
(2) 如何实现 KISS?
①避免过度设计
- 不要为了显示自己的编程技巧而编写复杂的代码。
- 简单的代码更容易理解、调试和维护。
②使用明确的命名
- 变量、函数和类的命名应尽量清晰、明确,能够反映其用途。
- 避免使用晦涩难懂的缩写或不相关的命名。
③分解问题
- 将复杂的问题分解为多个简单的小问题,每个小问题用一个简单的函数或方法来解决。
- 避免在一个函数或方法中处理过多的逻辑。
④遵循单一职责原则
- 每个函数或类应只负责一个职责或任务。
- 这样可以避免代码过于复杂,并提高代码的可维护性。
⑤重用现有工具和库
- 不要重复发明轮子,尽量使用现有的工具和库来解决问题。
- 这不仅可以减少代码量,还可以提高代码的可靠性和可维护性。
3. Refactor
Refactor(重构)是指在不改变代码外部行为的前提下,对代码内部结构进行调整,以提高代码的可读性、可维护性和性能。
(1) 重构核心思想
重构的核心思想是通过逐步改进代码结构,使其更易于理解和维护,重构不是一次性的大改动,而是通过一系列的小步骤逐步优化代码。
(2) 重构的好处
- 提高代码可读性:重构后的代码更加简洁、清晰,便于理解。
- 提高代码可维护性:减少代码中的重复和冗余,使得修改和扩展代码更加容易。
- 减少错误:通过清晰的代码结构和逻辑,减少潜在的错误和Bug。
- 提高开发效率:重构后的代码更易于测试和调试,从而提高开发效率。
(3) 重构常见技巧
①提取方法
- 将一段复杂的代码提取到一个独立的方法中,使原方法更加简洁。
- 有助于提高代码的可读性和复用性。
②重命名
- 使用有意义的命名来替代晦涩难懂的命名。
- 提高代码的可读性和理解性。
③内联方法
- 如果一个方法的实现非常简单,可以将其直接替换到调用处。
- 减少不必要的方法调用,提高代码的简洁性。
④替换魔法数字
- 将代码中的硬编码数值替换为有意义的常量。
- 提高代码的可读性和可维护性。
⑤提取类
- 将一个类中职责过多的部分提取到一个新的类中。
- 遵循单一职责原则,使类的职责更加明确。
⑥合并重复代码
- 将重复的代码提取到一个独立的方法或类中。
- 遵循DRY(Don't Repeat Yourself)原则,提高代码的复用性。
4. SOLID
SOLID是 Robert C. Martin(也称为Uncle Bob)提出或者总结出来的经典之作。它可以适用于各种编程语言,通常会用来衡量一个模块,系统设计的是否合理。
(1) SOLID是什么?
在 架构整洁之道 这本经典的书籍中有一套关于软件设计的 SOLID 原则,SOLID 实际上是五个设计原则首字母的缩写,它们分别是:
- 单一职责原则(Single responsibility principle, SRP)
- 开放封闭原则(Open–closed principle, OCP)
- Liskov 替换原则(Liskov substitution principle, LSP)
- 接口隔离原则(Interface segregation principle, ISP)
- 依赖倒置原则(Dependency inversion principle, DIP)
5. Document Your Code
Document Your Code(记录你的代码,简称 DYC),旨在提高代码的可读性、可维护性和可扩展性。通过在代码中添加注释和文档,可以帮助自己和他人更好地理解代码的意图、逻辑和功能。
(1) DYC 核心思想
DYC 的核心思想是通过详细的注释和文档,使代码更加易于理解和维护。这不仅对当前的开发工作有帮助,对于未来的维护、调试和扩展也至关重要。
(2) 如何实现 DYC?
①添加注释
- 在代码的关键部分添加注释,解释代码的意图和逻辑。
- 注释应简洁明了,避免冗长和重复。
②编写文档
- 为复杂的模块、类和方法编写详细的文档,解释它们的功能、用途和使用方法。
- 文档可以包括设计文档、API文档、用户手册等。
③使用自解释代码
- 通过使用有意义的变量名、函数名和类名,使代码自解释。
- 尽量减少对注释的依赖,但在必要时仍应添加注释。
④保持文档更新
- 在修改代码时,及时更新相关的注释和文档。
- 确保文档与代码保持一致,避免文档过时。
⑤使用工具
- 使用文档生成工具(如 Java 的 Javadoc)自动生成API文档。
- 使用版本控制系统(如 Git)来跟踪文档的变化。
⑥Creation Over Legacy
- Creation Over Legacy(创建优于继承,简称 COL)原则主要应用于面向对象编程(OOP)中,强调通过对象的组合和创建来实现复杂行为,而不是通过继承。
(3) COL 的核心思想
COL的核心思想是通过对象的组合和创建来实现复杂行为,而不是依赖继承。这有助于保持系统的灵活性、可维护性和可扩展性。
(4) 为什么选择 COL?
①减少复杂性
- 继承层次结构过深会导致系统复杂性增加,难以理解和维护。
- 通过组合,可以将复杂行为分解为多个独立的、易于理解的小对象。
②提高灵活性
- 组合比继承更灵活,可以在运行时动态地改变对象的行为。
- 通过依赖注入,可以轻松替换和扩展对象的功能。
③增强可测试性
- 组合和依赖注入使得单元测试更加容易,因为可以轻松地模拟和替换依赖对象。
- 避免了继承层次结构中常见的耦合问题。
如果你用面向对象编程(OOP)来编写代码,你会发现这个规则非常有用,创建优于继承的规则主要是关于具有复杂行为的对象由具有不同行为的对象实例组成,它们不应添加新行为并继承一个类。
依赖继承会导致两个主要问题:
- 首先,如果你尝试快速实现,继承层次结构会变得复杂。
- 其次,你在定义不同或特殊行为时灵活性较差。假设你需要实现共享行为:
7. Clean Code At All Costs
Clean Code At All Costs(始终保持代码清洁)原则强调代码的清晰、简洁和可维护性。无论在何种情况下,都应尽量保持代码的清洁。这不仅使得代码更易于理解和维护,还能提高软件的质量和开发效率。
(1) Clean Code 的核心思想
Clean Code 的核心思想是:编写易于阅读、理解和维护的代码。这意味着代码应该尽量避免复杂性、重复和不必要的冗长,同时保持逻辑的清晰和一致性。
(2) 如何实现 Clean Code?
①使用有意义的命名
- 变量、函数和类的命名应尽量清晰、明确,能够反映其用途。
- 避免使用晦涩难懂的缩写或不相关的命名。
②函数应简洁
- 每个函数应只做一件事,并且尽量短小。
- 如果函数过长或过于复杂,应考虑将其拆分为多个更小的函数。
③避免重复代码
- 遵循DRY(Don't Repeat Yourself)原则,将重复的代码提取为独立的函数或模块。
- 这样不仅减少了代码量,还提高了代码的可维护性。
④保持代码一致性
- 代码风格应保持一致,无论是命名、缩进还是注释风格等。
- 可以使用代码风格检查工具来确保一致性。
⑤注重代码结构
- 代码应有清晰的结构,逻辑应尽量直观和易于跟踪。
- 使用适当的注释和文档来解释复杂的逻辑和设计决策。
⑥避免深层嵌套
- 避免过深的嵌套结构,如过多的if-else或循环嵌套。
- 可以通过提前返回、使用卫语句等方式来简化嵌套结构。
⑦注重错误处理
- 错误处理应尽量明确和简单,不应隐藏错误或忽略异常。
- 使用适当的异常处理机制,并提供有意义的错误信息。
⑧YAGNI
YAGNI,全称 You Aren't Gonna Need It(你不需要它),它是极限编程(Extreme Programming,XP)中的一项重要原则,旨在提醒开发人员不要编写那些当前不需要的功能或代码。YAGNI原则的核心思想是:只实现当前需求所必须的功能,不要为未来可能需要的功能编写代码。
(3) YAGNI 原则的核心思想
YAGNI原则的核心思想是:避免过度设计和过早优化,只实现当前需求所必须的功能。这样可以减少代码的复杂性、提高开发效率和代码质量。
(4) 为什么选择 YAGNI 原则?
①减少复杂性
- 过多的功能和代码会增加系统的复杂性,难以理解和维护。
- 只实现当前需求,可以使代码更加简洁和易于管理。
②提高开发效率
- 实现不必要的功能会浪费时间和资源,降低开发效率。
- 专注于当前需求,可以更快地交付功能和产品。
③减少错误
- 不必要的功能和代码会引入更多的错误和 Bug,增加测试和调试的难度。
- 只实现当前需求,可以减少潜在的错误和 Bug。
④增强灵活性
- 未来的需求可能会变化,过早实现的功能可能会变得不再适用。
- 只实现当前需求,可以保持系统的灵活性,便于将来根据实际需求进行调整。
9. Delegation Principles
委托原则(Delegation Principles)强调将任务或职责委托给适当的对象或方法来完成,而不是由当前对象直接实现。这种方式可以提高代码的灵活性、可维护性和可复用性。
(1) 委托原则的核心思想
委托原则的核心思想是:将任务或职责委托给最适合处理它的对象或方法。通过这种方式,可以减少代码的耦合度,增强代码的灵活性和可复用性。
(2) 为什么选择委托原则?
①提高灵活性
- 委托可以让对象在运行时动态地决定由谁来处理任务。
- 这使得系统更具适应性和扩展性。
②减少耦合
- 通过委托,类之间的依赖关系减少,降低了耦合度。
- 这使得代码更容易理解和维护。
③增强可复用性
- 委托可以让不同的对象共享相同的行为,从而提高代码的复用性。
- 这减少了代码的重复,提高了开发效率。
④提高测试性
- 通过委托,可以轻松地替换或模拟被委托的对象,增强了代码的可测试性。
- 这使得单元测试更加容易。
10. Encapsulate the Changes
在软件领域,唯一不变的就是变化。所以,总是将你认为将来可能需要编辑的代码封装起来。
Encapsulate the Changes(封装变化),旨在将可能变化的部分隔离和封装起来,使得系统的其他部分不受这些变化的影响。通过封装变化,可以提高代码的可维护性、可扩展性和稳定性。
(1) 封装变化核心思想
封装变化的核心思想是:将变化的部分封装在一个独立的模块、类或方法中,使得系统的其他部分不依赖于这些变化。这样可以减少代码的耦合度,提高系统的灵活性和可维护性。
(2) 为什么选择封装变化?
①提高可维护性
- 通过封装变化,代码的修改只需在一个地方进行,减少了维护的复杂性。
- 这使得代码更容易理解和管理。
②提高可扩展性
- 封装变化使得添加新功能或修改现有功能变得更容易,而不会影响系统的其他部分。
- 这有助于系统的扩展和演进。
③减少耦合
- 通过封装变化,可以减少代码之间的依赖关系,使得系统更加模块化。
- 这有助于提高代码的复用性和灵活性。
④提高稳定性
- 封装变化可以减少因修改代码而引入的错误,提高系统的稳定性。
- 这有助于确保系统的可靠性和可预测性。
Java中的许多设计模式使用封装。封装的一个例子是工厂设计模式。该设计模式封装了对象创建的代码,使你在以后引入新应用程序或网站时更灵活,而不会影响当前代码。
11. Favor Composition Instead of Inheritance
Favor Composition Instead of Inheritance(优先使用组合而不是继承)原则是软件设计中的一个重要原则,特别是在面向对象编程(OOP)中,该原则强调优先使用对象组合来实现功能,而不是通过继承来扩展类的功能。
(1) 优先使用组合核心思想
Favor Composition Instead of Inheritance 的核心思想是通过组合多个对象来实现复杂功能,而不是通过继承来扩展类的功能。这种方式可以提高代码的灵活性、可维护性和可复用性。
(2) 为什么选择优先使用组合?
①减少耦合
- 继承会导致子类与父类之间的强耦合,子类高度依赖父类的实现。
- 组合可以减少这种耦合,使得对象之间的依赖关系更加松散。
②提高灵活性
- 通过组合,可以动态地改变对象的行为,而继承则是在编译时决定的。
- 组合使得系统更具适应性和扩展性。
③增强可复用性
- 组合可以将多个小对象组合成更复杂的行为,从而提高代码的复用性。
- 这减少了代码的重复,提高了开发效率。
总结
编程是一个看似简单,但是还是有很大学问,特别是编写出高质量的优雅代码,最后我们再总结下本文总结的 11种原则:
- DRY,Don't Repeat Yourself
- KISS,Keep It Simple And Stupid
- Refactor
- SOLID
- Document Your Code
- Creation Over Legacy
- YAGNI,You Aren't Gonna Need It
- Delegation Principles
- Clean Code At All Costs
- Encapsulate the Changes
- Favor Composition Instead of Inheritance