Interfaces vs. Abstract Classes

When should I choose to design using interfaces and when should I choose to use Abstract Classes?

Interfaces’ purpose in life is much more clear than abstract classes: they’re meant to define a “contract” between a client and a server.  They prescribe a precice way that two components communicate with one another.  They provide a means of component interchangeability.

Abstract Classes provide the same benefits of “interchangeability” and polymorphism.  However, Abstract Classes have a few limitations.  Here’s an overview of the differences and the implications:

Classes may only inherit from one Abstract Class, whereas classes may inherit from multiple interfaces

The implication of this fact helps us understand the real measning behind interfaces.  Interfaces define a “prescribed capability” wheras abstract classes define a “design contract”.

This quality of “prescribed capability” is apparent in most well written component oriented code, and is illustrated by the fact that most interface names are adjectives related to a verb.  For example, some common .net interfaces are:

·  IComparable

·  ISerializable

·  IEquatable

· IFormattable

The “…able” suffix affirms this concept even more.  Interfaces describe an object’s “capabilities”.  Interfaces are used when one component attempts to determine whether or not another component supports a certain capability.  If it does, then the component can be used.  The details of how the actual object behind the interface implements the prescribed capabilities is of no concern to the client. 

So it makes sense that a class would be able to inherit multiple interfaces – a component based framework allows any given component to fulfill more than one capability.

Further more, using the concept of prescribed capabilities (i.e. adverbs) to design class interfaces leads to much more robust and elegent software designs.  The book “Head First Design Patterns” provides good insight into this concept in its introduction in which they recommend thinking of interfaces interms of “behaviors a class may support” rather than “a generic type of class”.

So interfaces really should be used to describe behavior capability. 

Designing around behavior capability is less intuitive and designing around types.

Wheras interfaces are tailord to describing behaviors, abstract classes are more tailored to describing types.

We said before that “designing against capabilities rather than types” leads to more elegent designs.  While this is true in terms of the overall structure of a software system, it does not mean that there are not benefits to designing against types.

Abstract Classes allow a way of providing a “design contract” rather than a “behavior contract”.  A design contract helps a designer understand how a derived class should “look” rather than “behaive”.  A design contract influences the backend design of a system rather than the front end.  It provides a way of enforsing certain design rules when designing derived classes or creating implementations of interfaces.

[There are two issues: 1) Enforcing a common external design – enforcing how a component should be used, 2) Enforcing a common internal design – enforcing how various implementations of an interface are built.  Theres a lot more here!] 

Another benefit of Abstract Classes is that they are actual classes, which in .net means that they’re System.Objects.  System.Objects have a lot of benefits:

-       Type conversion

-       Serialization (I think…)

-       Others?

A General Purpose Template 

So which do we use?  Use both!

Interface              ILoadable, IPlayable

    ^

Abstract Class         Bscan

    ^

Concrete Classes       M9Bscan, CorelisBscan

 

In conclusion, although interfaces and abastract classes are very similar from semantic and binary perspectives, they have quite different purposes and in terms of design should be used differently.

Guidelines

-       Abstract Classes should be as abstract as possible; i.e. they should look as much like interfaces as possible

-       “default behavior” should be used with care

-       Class Properties should not be interfaces

Calling Static Method Using Reflection

I was loading an assembly that contained a class that derived from a class which was defined in my assembly.  I wanted to call a static method in that assembly, so I used the Reflection GetMethod and Invoke calls.  Then I realized, that the static method was actully a static method of the class defined in my assembly.  So instead of using GetMethod and Invoke I could have just called the static method directly.

Would there be a difference? 

Turns out that the static method is executed in the assembly in which it is defined, regardless of whether or not GetMethod and Invoke are called or if the method is called directly.

 

Testing BlogJet

I have installed an interesting application - BlogJet. It's a cool Windows client for my blog tool (as well as for other tools). Get your copy here: http://blogjet.com

"Computers are incredibly fast, accurate and stupid; humans are incredibly slow, inaccurate and brilliant; together they are powerful beyond imagination." -- Albert Einstein