Not All Interfaces are Built the Same
page 1 of 2
Published: 02 May 2007
An interface can mean many things and this article takes a look at a design where an abstract class was used and discusses how an interface, of any kind, is good for the developer.
by Stephen Rylander
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 14081/ 17
Article Contents:


In my last article I described using composition in the design of an object based system. In that article I included a simplified UML class diagram of some work I did to a fictitious Product object to display the use of composition.  Please see Figure 1 below. At the top of that diagram sits the class ProductBase.  It is an abstract class (a class that has abstract methods and cannot be instantiated).  But why is it abstract?

Figure 1 - Product UML


Let us first ask what could the class be marked as if it were not an abstract class?  Here, there are two options.  One, it could be a concrete class and two, it could be an interface.  Let us look at the concrete class first.

A concrete class is any class that is not abstract; it is just a class. The following code snippet contains a concrete class followed by an abstract class.

Listing 1 - Concrete and Abstract

public class StockStatus
public abstract class ProductBase
   abstract public StockStatus InventoryStatus{get;};

When a class is concrete that means the only way to extend the class is by inheriting from it.  That is often referred to as implementation inheritance or class inheritance because you are in essence inheriting all of the code and logic that went into the base class.  That is not something I wanted to do with the Product object because it blows up encapsulation and is very inflexible.

The second option was to use an interface.  Here, we would define an interface and then have ProductBase implement that interface.  In the future, we could then substitute any class that implemented the interface.

Listing 2 - Using an interface

public interface IProduct
   int GetNumberInStock();
public class ProductBase : IProduct
    public int GetNumberInStock()
       return 3;

In my first go around, this is basically what I had.  Of course, that is why design reviews are important.  It was pointed out by a coworker during a review that using an interface in this instance does not buy you anything more than using an abstract class, and if an abstract class were in fact used, we could mix in a little bit of implementation. Sounds good right?  At first I did not like it at all.

"That breaks encapsulation!" I bellowed across the table, and let it reverberate off the walls and deaf ears.  No one wanted to hear it. Why?  Because using an abstract class here was simply a better design decision. 

In this instance, a Product, no matter how many times subclassed, is a product.  It has properties and some core methods. So in our abstract class we defined all of our entity properties implementation but left the "Load" (of data) methods as abstract so that the implementing class could define those.  It ended up as an unintentional use of the template method, which is a good side effect of paying attention to your design. I believe that the decision is a mix of the best of both worlds. 

View Entire Article

User Comments

No comments posted yet.

Product Spotlight
Product Spotlight 

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2024  |  Page Processed at 2024-07-24 8:12:17 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search