关于DRY的理解

个人的理解：

如果我们对于一个功能，或者一个需求来说，重复次数达到3次以上，那么可以对其封装成一个组件。

但这里的封装，并不是把它进行抽象化，模版化，而是应该在满足当前项目需求的情况下来封装，也就是需求决定封装。

举个例子：

比如说，你每天都需要启动电脑的所有服务，在项目中链接你的数据库，以及数据库备份等等等，这些东西，看起来好像是使得你忙忙碌碌，但是，对于一个优秀的程序员来说，他可能化几天时间写个脚本，每天定时运行便代替了忙忙碌碌的你。

再比如说，你是一名不错的移动端开发工程师，在这次版本迭代中，你需要改某个视图的UI，你可能真的就只是重新写这个视图的UI，然后再重新写这个视图的逻辑。但是，对于细心的人，你可能就会发现，这里的逻辑业务层其实并没有改动，只是表现层需要变动而已，如果还有下一次，那就尽可能的将两者分离。

所以我的看法还是一样，需求决定封装。

相关文章：

1. Abstraction: The Rule Of ThreePosted by Derick Bailey on October 31, 2012

2. DRY的误区

3. Redundancy vs dependencies: which is worse? May 27th, 2008 | software

---

题外话：不要盲目的追求封装，抽象，何不再多想想到底适不适合。

转载于:https://my.oschina.net/CgShare/blog/506149