Should this code have been a Base class instead of an Interface?

Question

Interface vs. Base class is still a fairly gray area to me. I'm reading a book on ASP.NET 3.5 Enterprise Development and the author states that all tables will have the following fields:

InsertDate
InsertENTUserAccountId
UpdateDate
UpdateENTUserAccountId
Version

If this were me coding the above requirement, I would create a base business object class that contained these fields, and all business objects would inherit from it. However, the author has created these as an Interface instead. Bad idea? Good idea? Doesn't matter?

Update

There is a base class that implements this Interface. It appears that all business objects would then inherit from the base. But even still, I would have just put this Interface in the base class...?

Answer 1

If you never need to instantiate it, then it's an interface, otherwise, it's a base class.

Answer 2

Well, an interface is usually preferred as it allows greater flexibility and abstraction - but you can do both, by having your abstract base-class implement the interface. Then 95% of the time you use the base-class, and when you need something different you just use the interface.

Just don't touch the base-class from your business code... only the interface. The base-class is an implementation detail only.

Answer 3

By using an interface you are required to implement all those properties in all classes that implement the interface. If the implementation is the same for all, this is a lot of duplicated code. This can be mitigated by having a base class implement the interface.

By using a base class you can share the same implementation among all subclasses. Problems arise if you need to subclass something else, as .NET does not allow multiple inheritance. This way you will have to directly implement the interface (probably using composition).

Answer 4

He's guaranteeing they are in there without defining what they must be ahead of time. These also may be more related by behavior as opposed to direct inheritance. If they are behaviour relations and not directly inherited for the is-a relationship, then the interface is best, maybe only way to do it.

EDIT: if you think about it not all tables have the same data but they all have to do something with the account. This is the behavior relation as opposed to the is-a relationship, thus the Interface.

Answer 5

To define the common "contract" of the class, I would normally use an interface. I might then define an abstract base class that provides some default implementations and fulfills all or part of the "contract" defined by the interface. In cases where the implementation differs for every class I might omit the abstract base class. I won't typically define an abstract base class without an interface, though. It's also possible that my entities might implement several interfaces.

Answer 6

Kind of what the other guys said, but my simple way of thinking of it:

• If you want it to look the same from the outside, make it an interface.
• If you want it to be the same on the inside, make it a base class.
• You might want to do both.

Answer 7

I think the best way to look at an interface is: "a list services that will be provided by a class that implements that interface". An example would be ISwitchable, all classes that implement this interface provide a way (that is defined in the interface) to switch. An implementation of ISwitchable could be a button.

On the other hand, the base/sub-class relation can be described as: A subclass is a specialization of a base class. So if you have a pet as base class, you can have a dog derive from base since it is a specialization of a pet. You cannot say that a dog provides the pet service. In this example dog class can implement the IBrag interface.

I dont agree with some answer here that say "when" something should be an interface or base class. It is part of a modelling process, so it depends on the business objects and the context wether something should be an interface or a base-class.

Answer 8

Creating it as an interface only, would be a bad idea because of all the code duplication, in this case the most appropriate would be to do both, you can have a base class and a base interface from which all your other table-interfaces inherit from

IBaseInterface {
 //basic fields
}

ITable1Interface : IBaseInterface

BaseClass : IBaseInterface {
  //basic fields implementation
}

Table1Class : BaseClass...

Answer 9

I think you should think in interfaces like behaviors that a type should implement, without have to think about what this type is. They should be lightweight and allow extension to your objects and third party objects to come. Base class have more to do about family of classes that will inherit it, and so should have some semantic relation with. And, of course, you can use both, what is a possibility. You should have a interface ILoggable (I guess you're using that info for logging) or whatever, and based in your system architecture you can have one or more base classes that implements this interface to save you from coding repetitive code, for example, a AbstractPerson that will implement ILoggable and a Person object inherit it, this approach is extensible in the future, is easy to be implemented in somebody elses code, and gives you a flexibility.