Question

我有一个很大的'经理'课程，我认为这样做太多了，但我不确定如何将其划分为更合理的单元。

一般来说，该课程基本上由以下方法组成：

class FooBarManager
{
  GetFooEntities();
  AddFooEntity(..);
  UpdateFooEntity(..);
  SubmitFooEntity(..);
  GetFooTypes();
  GetBarEntities();
}

Manager类是我的业务逻辑的一部分，并在数据访问级别上构建另一个“Manager”类的实例，该类包含所有实体的所有CRUD操作。

我有来自数据访问层的不同实体，因此在Manager类之外有一个转换器，用于将数据实体转换为业务实体。

经理课程的原因是我希望能够在进行单元测试时模拟每个“经理”课程。每个经理类现在超过1000个loc，每个包含40-50个方法。我认为它们非常臃肿，并且发现将所有数据访问逻辑放入一个类很尴尬。我应该做些什么？

我如何分割它们？我应该使用任何特定的设计模式吗？

Answer 1

除非它是通用的，否则你真的不应该将所有数据访问权限放在一个类中。我首先将您的数据访问类拆分为每个对象或相关对象组的一个管理器，即CompanyManager，CustomerManager等。如果您需要通过一个“上帝类”访问管理器，您可以拥有每个管理器的实例在你真正的经理班里。

Answer 2

您的FooBarManager看起来很像God Object反模式。

在像你这样的情况下，考虑由Martin Fowler钻研Patterns of Enterprise Application Architecture。乍一看，您似乎想要创建Data Mapper。但是考虑像Active Record这样的替代方案，这可能足以满足您的需求。

另请考虑为您的平台使用ORM library/software。在没有充分理由的情况下建立自己的只会面对许多已经或多或少地通过这些工具解决的问题。

Answer 3

       / FooManager
Manager                  (derive from Manager)
       \ BarManager

应该是自我解释

Answer 4

我建议使用作文。想想经理正在做的功能。按照单一责任划分他们。看起来大多数FooBarManager是Foo和bar实体的集合。因此，至少要从FooBarManager中删除集合逻辑

public class EntityCollection<T> : IList<T> 
 where T : BaseEntity
{ /* all management logic here */}
public class FooCollection : EntityCollection<foo> {}
public class BarCollection : EntityCollection<bar> {}
public class FooBarManager 
{ 
public FooCollection { /*...*/ } 
public BarCollection { /*...*/ } 
public FooBarManager() : this(new FooCollection(), new BarCollection()){}
public FooBarManager(FooCollection fc, BarCollection bc) { /*...*/ } 
}

我应该如何将大型和膨胀的类分成较小的类？

4 个答案: