首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >实现类似的UseCases类似于代码复制

实现类似的UseCases类似于代码复制
EN

Stack Overflow用户
提问于 2015-06-24 09:30:07
回答 1查看 206关注 0票数 7

我有下面的案子。用户可以将多种对象类型(交易、发票等)导出到外部会计系统。导出算法有步骤:

  • 通过某种筛选器获取对象
  • 将对象逐个导出到会计系统(每种对象类型的web服务方法)
  • 注册给定文档已被导出的事实,因此不会再次导出。
  • 为用户准备摘要(导出文档、错误信息等)

对于所有对象类型,算法是相同的,但是有一些重要的区别必须处理:

  • 不同类型
  • 不同的目标web服务方法,不同的对象到DTO映射
  • 每个对象类型的不同过滤器

我考虑了几个解决方案:

  • 不要将导出算法视为代码复制,并实现每种对象类型的算法。将任何数据导出到任何外部系统都可以用这种算法来描述--这是否意味着我们应该始终有一个通用类来将任何数据导出到任何地方?)
  • 将差异移到策略(为所有差异创建抽象的一个策略接口)--我甚至实现了它。
  • 使用泛型--不幸的是,我正在用PHP编写代码,这是不可能的

问题:

创建每个对象类型的单独导出算法是否是代码复制?

也许所有这些都应该作为单独的用例来处理?

如果这是一个重复,那么我应该考虑哪些技术来避免它呢?

对我的第一个实现的描述:

在第一种方法中,我定义了一个可导出的抽象,但我对此并不满意。每个对象都有完全不同的有效载荷。一个可导出的接口只定义了一个方法getId,它被用来注册被导出的对象(由于它不会再次导出)。为此目的,抽象是很好的,但是问题转移到exportService,它必须检查具体实例以选择DTO和端点。所以exportService破裂了。

EN

回答 1

Stack Overflow用户

发布于 2015-06-24 13:22:01

上面所描述的没有一个是特定于领域的逻辑(事实上你甚至在你的问题中都没有提到问题领域),所以我不认为它真的属于领域驱动的设计。因为这不是特定于领域的逻辑,所以我不会太担心代码复制,特别是考虑到解决方案似乎并不明显。

保持简单,只需分别写出每个用例。如果您发现有一些很容易重构的通用代码,那么在所有事情顺利运行之后,就可以这样做了。在显然有必要之前,不要过度考虑或添加模式。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/31022820

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档