有必要对代码中的业务逻辑做类似的抽象吗？

举个例子，公司现有Web项目中有图书类的栏目，包括有图书信息、审核、上传、网友点赞评论群组以及一系列的后台管理等等功能。

现在新的需求是准备开设电影栏目，而功能和原有的图书类“基本”保持一致。那么为了尽可能的重用现有的图书类的功能，我们打算扩展现有的图书类，增加一个称为“媒体”的新类，并添加一个Type字段来区分图书或者电影或者以后任何其他类型的扩展。这么做就可以避免重写那些已经在图书中实现过的那些功能。（听上去这么做应该很快，实际上未必如此，你要面对在刚开始做图书功能时留下的一些Hardcode）

我的疑问是，目前这么做的前提条件是以保证图书和电影这两类功能基本一致作为前提的。如果一旦业务需要根据不同媒体类型做出改变（这种情况几乎是一定的，对吧），那就又要从原有的逻辑中分离出不同的情况来处理，这就等于又走了回头路。

既然会有这样的情况发生，那么是不是直接复制一份原有的图书的代码，重命名为电影，然后稍加整理代码中的名称，这样岂不是更简单？虽然这样做听上去很没有技术含量，但是至少可以轻松面对业务在任何一边发生变动，都不会影响其他功能。虽然从程序员的角度来说，同样的代码你可能有了两份拷贝，增加了维护的成本，从直觉上会有一种去合并他们的冲动，但是从业务逻辑上来说，他们毕竟是两个不怎么相关的东西（尽管会有人向你保证它们之间的功能很“像”），你很难预测产品那边会把需求改成什么样子。

另外，对于拷贝代码的做法可能说的有点简单，事实上可能不会真那么简单去做，比如上传功能就可以作为一个公共组件抽象出去、群组、评论等等周边功能都可以抽离出去，包括看不见的缓存等等，而和图书、电影相关的一些最基本的代码还是保持分离，这样做是不是一个更正确的姿势？

（举例中关于图书、电影的需求内容只是我虚构的，不用纠结）