Question

我需要一个我的DTO类的基类，它将在我的通用接口中使用。

但DTO课程没有任何共同之处。它们只是包含一些属性的哑类。

public void GetGridData()
{

   IDataForGrid<DTOBase> aa;

   if(request == 1) aa = new CustomerGridData;
   if(request == 2) aa = new OrderGridData;

   var coll = aa.GetList();
}

public class CustomerGridData : IDataForGrid<CustomerDTO>
{
  ...
}

Answer 1

如果他们共有 nothing ，那么您要对从列表中检索的实例做些什么呢？

在任何情况下，拥有基类意味着什么时候（好吧，如果）你识别出他们做之后需要共同拥有的东西，你就不会必须回去重构（重新）一切。但是我认为在任何情况下我都会考虑使用接口而不是基类，因为它听起来不太需要重用底层实现（因为它们没有任何共同之处！）。这取决于你认为他们最终可能会在以后共同拥有的东西。

Answer 2

这不是一个糟糕的设计，虽然有点不常见。可以这样想想 - 虽然没有任何缺点，但至少有两个好处：

基类充当接口的过滤器，因此您不能仅将任何对象传递给它们 - 只是您的DTO对象。标记接口也可以。
当他们最终得到一些共同点时，很容易将其添加到那里，你就不必重构所有内容。

Answer 3

.NET编码指南说，拥有一个空的基类或接口（也称为“标签”接口）确实是糟糕的风格。首选样式是使用属性来注释相同类的类。还有FxCop rule来执行此约定。

但是，有时（在极少数情况下）我使用这个习惯用法，即使没有常用功能，公共基类对于表示公共层次结构也很有用。属性不能用于此。

例如，在编程语言的解释器中，有几种方法返回一个特殊的基类Value，即在该编程语言中具有值的东西。基本上，这个值可以是所有从一个数字到一个字符串（它是特殊类，而不是System.Int32或System.String）到复合对象。我可以也返回System.Object，但这会使我公共界面的输入变弱。

良好的自我记录代码可以从受限制的界面中获利。

Answer 4

在java中，这称为Tag Interface。该链接提供了一些关于标记接口，它们的用途和问题的良好背景。

有一个空的基类坏设计？

4 个答案: