为自有实体解耦服务的设计模式是什么？

Question

我正在寻找一种设计模式或约定来解耦处理自有实体的服务。假设我有一个ThemeService，它负责创建主题。起初，ThemeService 只是为每个用户的UserData 保留主题，但需求发生变化，主题由其他实体拥有，例如 ThemeCollection。我的问题是，每个ThemeService 都与它们的“拥有”实体紧密耦合。例如：

public class ThemeService{
    //coupled to UserData
    createTheme(Theme t, UserData u);
    getTheme(String name, UserData u);
    hasTheme(String name, Userdata u); //Theme name unique within a userdata.
    validateTheme(Theme t, UserData u); //unique name per user, valid colors, etc.
}

public class UserDataService{
   ThemeService tService; //component for themes

   getUsername(UserData u);
   addTheme(Theme t, UserData u){ tService.createTheme(t, u); }
   getTheme(String name, UserData u){ tService.getTheme(name, u); }
   hasThemes(String name, UserData u){ tService.hasTheme(name, u); }
}

现在 ThemeService 与 UserData 紧密耦合。如果需求发生变化并且主题可以属于另一个实体，例如 ThemeCollection，那么我无法真正重用 ThemeService 中的大部分代码，现在需要更多代码来处理 ThemeCollection 内容：

public class ThemeService{
    //...continued or in another ThemeService class...
    createTheme(Theme t, ThemeCollection c);
    getTheme(String name, ThemeCollection c);
    hasTheme(String name, ThemeCollection c);
    validateTheme(Theme t, ThemeCollection c);
}

public class ThemeCollectionService{
   ThemeService tService;

   getCollectionName(ThemeCollection c);
   addTheme(Theme t, ThemeCollection c){ tService.createTheme(t, c); }
   getTheme(String name, ThemeCollection c){ tService.getTheme(name, c); }
   hasThemes(String name, ThemeCollection c){ tService.hasTheme(name, c); }
}

我很想让它采用一个通用参数来实现类似“Themeable”的东西。但是，这会使实体实现一个接口：

public class ThemeService{
    createTheme(Theme t, Themeable owner);
    getTheme(String name, Themeable owner);
    hasTheme(String name, Themeable owner);
    validateTheme(Theme t, Themeable owner);
}

@Entity
public class UserData implements Themeable{
   getUsername();
   getThemes(); //From Themable
}

@Entity
public class ThemeCollection implements Themeable{
   getUsername();
   getThemes(); //From Themable
}

我没有在 Themeable 接口中包含创建、获取、验证等，因为我不希望我的实体类中的业务逻辑应该是一个纯数据结构（在模型中包含业务逻辑是草率的根据罗伯特马丁的“清洁代码”，我正在尝试遵循一些标准）。

是否有标准的方式、模式、约定等来解耦？我所拥有的或多或少“好的”还是在生产环境中不受欢迎？我试图摆脱“完成工作”的代码，转向模块化和可重用的代码，因此非常感谢任何帮助和指针。

编辑：“为什么您的服务与两个实体耦合？”

我需要一个地方来将拥有实体和拥有实体“缝合”在一起。例如，为 UserData 创建主题：

public void createTheme(Theme t, UserData u){
   entityManager.persist(t);

   if(!hasTheme(t.name(), u){
      u.getThemes().add(t);
      entityManager.merge(u);
   }
}

所以这个函数与 UserData 耦合，任何类似的“主题所有者”都会有类似的代码。

Answer 1

一个好的方法是将主题集合的概念与用户分开。那么你有：

Class Theme
Class ThemeCollection  //all theme managment things go here
Class UserData  //has a member of type ThemeCollection

这样，与管理 Theme 相关的功能就在 ThemeCollection 中，可以在不同实体之间共享。