这是一个创建于 3605 天前的主题，其中的信息可能已经有所发展或是发生改变。
举个例子，公司现有Web项目中有图书类的栏目，包括有图书信息、审核、上传、网友点赞评论群组以及一系列的后台管理等等功能。
现在新的需求是准备开设电影栏目，而功能和原有的图书类“基本”保持一致。那么为了尽可能的重用现有的图书类的功能，我们打算扩展现有的图书类，增加一个称为“媒体”的新类，并添加一个Type字段来区分图书或者电影或者以后任何其他类型的扩展。这么做就可以避免重写那些已经在图书中实现过的那些功能。（听上去这么做应该很快，实际上未必如此，你要面对在刚开始做图书功能时留下的一些Hardcode）
我的疑问是，目前这么做的前提条件是以保证图书和电影这两类功能基本一致作为前提的。如果一旦业务需要根据不同媒体类型做出改变（这种情况几乎是一定的，对吧）， 那就又要从原有的逻辑中分离出不同的情况来处理，这就等于又走了回头路。
既然会有这样的情况发生，那么是不是直接复制一份原有的图书的代码，重命名为电影，然后稍加整理代码中的名称，这样岂不是更简单？虽然这样做听上去很没有技术含量，但是至少可以轻松面对业务在任何一边发生变动，都不会影响其他功能。虽然从程序员的角度来说，同样的代码你可能有了两份拷贝，增加了维护的成本，从直觉上会有一种去合并他们的冲动，但是从业务逻辑上来说，他们毕竟是两个不怎么相关的东西（尽管会有人向你保证它们之间的功能很“像”），你很难预测产品那边会把需求改成什么样子。
另外，对于拷贝代码的做法可能说的有点简单，事实上可能不会真那么简单去做，比如上传功能就可以作为一个公共组件抽象出去、群组、评论等等周边功能都可以抽离出去，包括看不见的缓存等等，而和图书、电影相关的一些最基本的代码还是保持分离，这样做是不是一个更正确的姿势？
（举例中关于图书、电影的需求内容只是我虚构的，不用纠结）
现在新的需求是准备开设电影栏目，而功能和原有的图书类“基本”保持一致。那么为了尽可能的重用现有的图书类的功能，我们打算扩展现有的图书类，增加一个称为“媒体”的新类，并添加一个Type字段来区分图书或者电影或者以后任何其他类型的扩展。这么做就可以避免重写那些已经在图书中实现过的那些功能。（听上去这么做应该很快，实际上未必如此，你要面对在刚开始做图书功能时留下的一些Hardcode）
我的疑问是，目前这么做的前提条件是以保证图书和电影这两类功能基本一致作为前提的。如果一旦业务需要根据不同媒体类型做出改变（这种情况几乎是一定的，对吧）， 那就又要从原有的逻辑中分离出不同的情况来处理，这就等于又走了回头路。
既然会有这样的情况发生，那么是不是直接复制一份原有的图书的代码，重命名为电影，然后稍加整理代码中的名称，这样岂不是更简单？虽然这样做听上去很没有技术含量，但是至少可以轻松面对业务在任何一边发生变动，都不会影响其他功能。虽然从程序员的角度来说，同样的代码你可能有了两份拷贝，增加了维护的成本，从直觉上会有一种去合并他们的冲动，但是从业务逻辑上来说，他们毕竟是两个不怎么相关的东西（尽管会有人向你保证它们之间的功能很“像”），你很难预测产品那边会把需求改成什么样子。
另外，对于拷贝代码的做法可能说的有点简单，事实上可能不会真那么简单去做，比如上传功能就可以作为一个公共组件抽象出去、群组、评论等等周边功能都可以抽离出去，包括看不见的缓存等等，而和图书、电影相关的一些最基本的代码还是保持分离，这样做是不是一个更正确的姿势？
（举例中关于图书、电影的需求内容只是我虚构的，不用纠结）
 |
1
chone 2015-01-11 12:53:46 +08:00 via iPhone  1
如果不想维护老的业务逻辑了可以这么干，但如果还要持续下去，重构增加一层抽象是必要的，不然这样的copy试想一下要对图书和新业务增加功能那不是每次都要copy相应的逻辑，这样两头维护会是个很大的负担。
|
 |
2
JamesRuan 2015-01-11 15:43:59 +08:00 via Android 1
我觉得应该把业务逻辑拆分成最小单元，而且是数据无关的。有新业务时，只需要对原有的逻辑组合做出调整。
面相向象用成了面向数据，才是这个问题出现的原因。如果把业务逻辑本身当做对象来做，把数据部分抽象出去，就不存在这个问题了。 时间充裕的应该是个重构的好时机了。 |
 |
3
tini8 2015-01-11 15:49:25 +08:00 1
业务逻辑千万别抽象，除非你是上帝
|
 |
4
levn 2015-01-11 16:05:04 +08:00 1
mixin?
|
Select Language