7

I need a base class for my DTO classes which will be used in my generic interfaces.

But the DTO classes have nothing in common. They are just dumb classes containing some properties.

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>
{
  ...
}
ЯegDwight
  • 24,821
  • 10
  • 45
  • 52
user137348
  • 10,166
  • 18
  • 69
  • 89
  • 3
    Object is an empty base class :) – Brian Rasmussen Mar 11 '10 at 10:54
  • 11
    @Brian - Object isn't empty :) – Mike Two Mar 11 '10 at 10:55
  • this is related to http://stackoverflow.com/questions/2424099/generic-interface-problem for background – Mike Two Mar 11 '10 at 10:56
  • @Mike: Well, if you want to split hairs. It doesn't have any data of its own. – Brian Rasmussen Mar 11 '10 at 11:01
  • @Brian - I wasn't trying to split hairs, but I'm not sure if I would agree that empty means no data. Because then a class with no data and no methods is even more emptier. – Mike Two Mar 11 '10 at 11:04
  • @Mike: Okay, fair enough. In that case there is no such thing as an empty base class in C#. I know that Object has methods and instances do in fact take up space on the heap even tough they have no retrievable state, so you're right Object isn't empty in that sense, but from a modelling perspective I would consider it empty. – Brian Rasmussen Mar 11 '10 at 11:09
  • @Brian - So now I think I might be splitting split hairs. Not trying to start an argument, I think we're at the immaterial difference level. Interestingly enough I was not approaching it from a memory usage perspective but a modelling perspective. If I inherit from Object do I get any fields, methods or properties? I do so from my view it isn't empty. However in the case of Object I would never draw it in a UML diagram or anything. So to me Object is empty for some value of empty. – Mike Two Mar 11 '10 at 11:25
  • @Mike: Let me retract the hair splitting comment then. I wasn't trying to start an argument either. In fact, I think we do agree. As you say Object is empty for some value of empty, and that what was I was referring to in my initial comment. If Object isn't empty, then no base class can be empty in C#. – Brian Rasmussen Mar 11 '10 at 12:04
  • Object does have data! It has a reference to a Type (vtable) and a Monitor. – Robert Fraser Mar 26 '10 at 03:14
  • EventArgs is an empty base class. – Pedro77 Jun 04 '13 at 18:42

4 Answers4

7

If they have nothing in common, what are you going to do with the instances you retrieve from your list?

In any case, having the base class means that when (okay, if) you identify something they do need to have in common later on, you don't have to go back and refactor (re-base) everything. But I'd consider using an interface rather than a base class for this sort of thing in any case, as it doesn't sound like there's a strong need to reuse underlying implementation (as they have nothing in common yet!). It'll depend on what you think they may end up having in common later on.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
7

It is not a bad design, although somewhat uncommon. Think of it this way - there are at least two benefits while there are no drawbacks:

  • The base class serves as a filter for your interfaces so that you can't pass just any object to them - just your DTO objects. Marker interfaces could to this too.
  • When they eventually do get something in common, it will be easy to add it there and you won't have to refactor everything.
Vilx-
  • 104,512
  • 87
  • 279
  • 422
4

The .NET coding guidelines say that having an empty base class or interface (also called “tag” interface) is indeed bad style. The preferred style is to use an attribute instead to annotate classes of the same kind. There is also an FxCop rule to enforce this convention.

However, I sometimes (in rare cases) use this idiom when a common base class is useful to denote a common hierarchy even if no common functionality exists. Attributes cannot be used for this.

For example, in an interpreter for a programming language several methods return a special base class Value, i.e. something which has a value inside that programming language. Basically, this value can be everything from a number to a string (which, are special classes, not System.Int32 or System.String) to a composite object. I could also return System.Object but this would make the typing of my public interface weaker.

Good, self-documenting code profits from the restricted interface.

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
  • 12
    A marker interface/class can server as a compile-time constraint so that you can't pass the wrong object to a method. Attributes can't do this. So I'm inclined to disagree with the guideline. – Vilx- Mar 11 '10 at 10:59
  • 1
    Was just about to post this link! http://msdn.microsoft.com/en-us/library/ms182128%28VS.80%29.aspx – Martin Smith Mar 11 '10 at 11:01
  • @Vilx: as am I (see the example I added). But it *is* an FxCop guideline. – Konrad Rudolph Mar 11 '10 at 11:01
1

In java this is called a Tag Interface. The link provides some good background on tag interfaces, their uses and issues.

Mike Two
  • 44,935
  • 9
  • 80
  • 96