关于DRY的理解

原创
2015/09/15 09:49
阅读数 151

个人的理解:

如果我们对于一个功能,或者一个需求来说,重复次数达到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


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

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
2 收藏
0
分享
返回顶部
顶部