代码抽象三原则

一、DRY（Don't repeat yourself）

解释：**不要重复自己** >多次遇到同样的问题，就应该**抽象**出一个通用的解决方法，而不是重复同样的代码。

二、YAGNI（You aren't gonna need it）

解释：**你不会需要它** > 除了最核心的功能，其他功能一概不要部署，尽可能快、尽可能简单地让软件运行起来。 > 即**不要为了抽象而抽象**，不要让代码一开始就变成华而不实的空中楼阁。

三、Rule Of Three

解释：**三次原则** > 第一次用到某个功能时，你写一个特定的解决方法； >第二次又用到的时候，你拷贝上一次的代码； >第三次出现的时候，你才着手"抽象化"，写出通用的解决方法。 > >理由： >（1）省事。如果一种功能只有一到两个地方会用到，就不需要在"抽象化"上面耗费时间了。 >（2）容易发现模式。"抽象化"需要找到问题的模式，问题出现的场合越多，就越容易看出模式，从而可以更准确地"抽象化"。 >（3）防止过度冗余。如果一种功能同时有多个实现，管理起来非常麻烦，修改的时候需要修改多处。在实际工作中，重复实现最多可以容忍出现一次，再多就无法接受了。

总结语：

该抽象的时候一定要抽象，不该抽象的时候就不要抽象，事不过三，三次或以上的重复代码再做抽象化。

参考：
http://www.ruanyifeng.com/blog/2013/01/abstraction_principles.html