|
锁定老帖子 主题：关于代码的可重用性
精华帖 (1) :: 良好帖 (0) :: 新手帖 (6) :: 隐藏帖 (24)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-07-27
关于这个关键还是“度”。
|
| 返回顶楼 | |
|
发表时间：2009-07-27
yiqixiaolong 写道 大家老说重构，我很想知道代码的重构跟代码的重用有什么关系。
这里有一共136页的试读：http://www.china-pub.com/computers/common/mianfeisd.asp?id=12901 可以点击顶部那个“翻阅”试读。 |
| 返回顶楼 | |
|
发表时间：2009-07-27
TheMarine 写道 yiqixiaolong 写道 大家老说重构，我很想知道代码的重构跟代码的重用有什么关系。
硬要说联系,那么重用是重构的结果.重构好了,就可以重用了.说了那么多,举一简单例子,人有动作吃饭,现在场景需要描述你的吃饭和你弟弟的吃饭,你先吃主食再喝汤,你弟弟喜欢先喝汤再吃主食.按照你的写法,你会写成if(我)else if(弟弟),然后在2组大括号里写你的逻辑.重构就是把吃主食和喝汤抽出来作为单个方法;把你和弟弟实现为2个类,实现统一接口我的家人,都有吃饭动作,那么原来的代码利用多态可以去除if else,只要写我的家人.吃饭().好处在于以后修改和增加逻辑的时候不必修改此处. 但是但是但是,我和弟弟到底是不是应该是2个对象,这个对象有意义吗,是实体吗,那个接口在这里合适吗?都是需要斟酌的.不要为了让代码可以重用而随便的抽象对象(就象很多教科书说继承是为了重用代码,这个是很不正确的),这个也就是所谓过度设计,一定要吃准业务,还原一个真实的世界,这样你才会在做复杂项目中收益.以上是我的观点,欢迎拍砖指正. 我认为你说很对，我现在就是陷入了过度设计的误区了，经常听大手们说代码是写的越少越好，于是就为了让代码变得更少而“重构”代码，代码就因此越来越难看，越来越难懂，最让我郁闷的是业务逻辑经常改变，重构出来的代码需要不断地打补丁才能适应，反倒不如不重构了。 |
| 返回顶楼 | |
|
发表时间：2009-07-27
最后修改：2009-07-27
yiqixiaolong 写道 TheMarine 写道 yiqixiaolong 写道 大家老说重构，我很想知道代码的重构跟代码的重用有什么关系。
硬要说联系,那么重用是重构的结果.重构好了,就可以重用了.说了那么多,举一简单例子,人有动作吃饭,现在场景需要描述你的吃饭和你弟弟的吃饭,你先吃主食再喝汤,你弟弟喜欢先喝汤再吃主食.按照你的写法,你会写成if(我)else if(弟弟),然后在2组大括号里写你的逻辑.重构就是把吃主食和喝汤抽出来作为单个方法;把你和弟弟实现为2个类,实现统一接口我的家人,都有吃饭动作,那么原来的代码利用多态可以去除if else,只要写我的家人.吃饭().好处在于以后修改和增加逻辑的时候不必修改此处. 但是但是但是,我和弟弟到底是不是应该是2个对象,这个对象有意义吗,是实体吗,那个接口在这里合适吗?都是需要斟酌的.不要为了让代码可以重用而随便的抽象对象(就象很多教科书说继承是为了重用代码,这个是很不正确的),这个也就是所谓过度设计,一定要吃准业务,还原一个真实的世界,这样你才会在做复杂项目中收益.以上是我的观点,欢迎拍砖指正. 我认为你说很对，我现在就是陷入了过度设计的误区了，经常听大手们说代码是写的越少越好，于是就为了让代码变得更少而“重构”代码，代码就因此越来越难看，越来越难懂，最让我郁闷的是业务逻辑经常改变，重构出来的代码需要不断地打补丁才能适应，反倒不如不重构了。 重构的目标之一就是使代码更加清晰。你这样说又让我觉得其实你的问题不在于代码级别的，重构也许已经不能使你更轻松了。一般来说，要解决的问题本身一般是不会大变的（至少大方向一致），那么原因不是客户说不清楚自己的业务逻辑或者遗忘逻辑，就是设计人员误解逻辑，开发人员又再次误解。在业务不清晰的情况下要做到灵活的设计几乎是不可能的，不是开发人员杜撰可能的情况，就是遗漏真正可能发生的。我们需要不断的精炼出真实的业务逻辑，需要更大概念上的重构。 |
| 返回顶楼 | |
|
发表时间：2009-07-27
yiqixiaolong 写道 TheMarine 写道 yiqixiaolong 写道 大家老说重构，我很想知道代码的重构跟代码的重用有什么关系。
硬要说联系,那么重用是重构的结果.重构好了,就可以重用了.说了那么多,举一简单例子,人有动作吃饭,现在场景需要描述你的吃饭和你弟弟的吃饭,你先吃主食再喝汤,你弟弟喜欢先喝汤再吃主食.按照你的写法,你会写成if(我)else if(弟弟),然后在2组大括号里写你的逻辑.重构就是把吃主食和喝汤抽出来作为单个方法;把你和弟弟实现为2个类,实现统一接口我的家人,都有吃饭动作,那么原来的代码利用多态可以去除if else,只要写我的家人.吃饭().好处在于以后修改和增加逻辑的时候不必修改此处. 但是但是但是,我和弟弟到底是不是应该是2个对象,这个对象有意义吗,是实体吗,那个接口在这里合适吗?都是需要斟酌的.不要为了让代码可以重用而随便的抽象对象(就象很多教科书说继承是为了重用代码,这个是很不正确的),这个也就是所谓过度设计,一定要吃准业务,还原一个真实的世界,这样你才会在做复杂项目中收益.以上是我的观点,欢迎拍砖指正. 我认为你说很对，我现在就是陷入了过度设计的误区了，经常听大手们说代码是写的越少越好，于是就为了让代码变得更少而“重构”代码，代码就因此越来越难看，越来越难懂，最让我郁闷的是业务逻辑经常改变，重构出来的代码需要不断地打补丁才能适应，反倒不如不重构了。 你可以试着把这些可能会变的业务部份抽取出来。这些部份集中改变，而尽量保持不容易变的部份，不要动。 如果变化是没有共通点可以抓的话，那就很难办了。。。 |
| 返回顶楼 | |
|
发表时间：2009-07-28
yiqixiaolong 写道 大家老说重构，我很想知道代码的重构跟代码的重用有什么关系。
并没有直接的关系，但是重构最终会给重用带来好处，因为重构的直接目的是为了让代码更加清晰易懂。清晰易懂的代码自然是易于重用的。 |
| 返回顶楼 | |
|
发表时间：2009-07-28
最后修改：2009-07-28
抛出异常的爱 写道 无论是否有人能作的更好........但看这样的东西真的会掉很多头发的...
你就当看推理小说吧。 
|
| 返回顶楼 | |
|
发表时间：2009-07-30
写if else也能叫重用
重用是抽象出公共的东西 |
| 返回顶楼 | |
|
发表时间：2009-07-31
类的重用呢？抽象，继承
|
| 返回顶楼 | |
|
发表时间：2009-08-11
哈哈，这个问题见山是山见水是水。一个东西没有抽象，何来重用？例如我写的一段代码，只是为了1+1这种特定的需求而实现，你怎么能做到处理a+b这中情况？明天是2+1，你就需要做个if。还在烦恼为什么老有变化，其实你不能抽象，不能将不变的部分进行分离，拿着部分代码基本是没有重用的可能的。重构只是为了代码更好理解，也许是为重用进行了设计，但总的说来不是本质。
|
| 返回顶楼 | |
