面向对象的经典设计原则——KISS，YAGNI，DRY

设计模式之美 - 20

• 怎么理解 KISS 原则中“简单”两个字？
• 什么样的代码才算“简单”？
• 怎样的代码才算“复杂”？
• 如何才能写出“简单”的代码？
• YAGNI 原则跟 KISS 原则说的是一回事吗？
• 只要两段代码长得一样，那就是违反 DRY 原则了吗？

---

一、KISS 原则 Keep It Short and Simple 翻译成中文就是：尽量保持简单 

• 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。
• 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高。
• 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。

---

二、YAGNI 原则 You Ain’t Gonna Need It 翻譯過來的意思就是：不要去设计当前用不到的功能；

这条原则的核心思想就是：不要做过度设计

---

三、DRY原则 Don’t Repeat Yourself。翻譯過來的意思就是：不要寫重複的代碼。

1、实现逻辑重复

在判断是否要合并相同的实现逻辑，需要同时考虑到 “单一职责原则” 和 “接口隔离原则”

例如：目前isValidUserName() 和 isValidPassword() 两个方法，如果判断逻辑完全相同，那么我可以为isValidUserNameOrPassword()方法吗？单从名字上看，我们就能发现，合并之后的 isValidUserNameOrPassword() 函数，负责两件事情：验证用户名和验证密码，违反了“单一职责原则”和“接口隔离原则”。如果之后还修改密码的判断逻辑，那么这个方法修改起来就会不变得负责、

2、功能语义重复

不要存在功能相同的两种方法。日后会不知道用哪个，迭代功能，也需要改多个。

3、代码执行重复

减少相同的IO操作。

---

四、代码的可复用性方法：

• 减少代码耦合
• 满足单一职责原则
• 模块化
• 业务与非业务逻辑分离
• 通用代码下沉：从分层的角度来看，越底层的代码越通用、会被越多的模块调用，越应该设计得足够可复用。
• 继承、多态、抽象、封装
• 应用模板等设计模式