abstract vs interface  
Author Message

PostPosted: Architecture General, abstract vs interface Top

hi everybody,

In my current application,ther is a common fucntionality(method) which can change frequently.

Should i use the abstract class or the interface to put the signature of the method (no body )inside.

The answer which comes in my mind is interface but then why can't we use abstract instead by just giving the signature of method in the abstract class.

Do interfaces or abstract differ in how much memory they consume and also in the performance of the application.

Please elaborate on what is to be used prefably in which scenarios as i read many articles but none of them gives indepth knowledge.


Udi Dahan The Software Simplist

PostPosted: Architecture General, abstract vs interface Top

Interfaces are preferrable for a number of reasons.

They enable implementors to have a different base class avoiding the problem of multiple inheritance.

THey increase modularity since you won't have the problem of changing code in the abstract base class that can break subclasses.

Abstract classes give you slightly better performance, but not anything you'd notice - on the scale of single digit percentage, but since they're both in memory, chances are they're not the bottleneck of the system, so don't waste any time on their performance.


PostPosted: Architecture General, abstract vs interface Top

You are right in thinking that you need to use interface here. Interface is all goodness.

The only accusation which I have heard about interfaces which sticks - is that it makes it complicated to read code. It becomes difficult to know which implementation is actually being invoked - if you read the code starting from the client side.

You can also consider looking at design patterns which enable loose coupling - like proxy pattern and registry pattern which can enable you to make a runtime decision of which implementation to use.



PostPosted: Architecture General, abstract vs interface Top

My criteria of using abstract vs interface is as follows:

If a class is a type of another class, I use abstract class because abstract class support inheritance. Example: PartTimeStaff and FullTimeStaff is a type of Staff.

If a class is not a type of another class but they have common function, I use inheritance. Example: FullTimeStaff and Customer should not come from the same base class but they may have common function, e.g. discountRate; in this case, interface is more appropriate.

Konstantin Gonikman

PostPosted: Architecture General, abstract vs interface Top

What about using Interfaces/Abstracts as contracts for WebServices Initially, I had my app using Interfaces for client/server .net-remoting communication, but as it was time to support web services, I stucked on it...

Diego Dagum

PostPosted: Architecture General, abstract vs interface Top

"Interfaces" sounds politically correct but still there are considerations you should care

Imagine you have a hierarchy of classes where some of them, near the root, implement some template logic that is inherited downward. Still that common logic isn't enough to define a whole instanciable class but a good mold you want to take advantage of, in order to narrow the implementation of a series of descendant classes, which differ just in minor details

Thinking in abstract classes here it's a good idea. But the question is... imagine a class A outside the hierarchy, such that A receives an instance of the hierarchy as argument of some method A.a(...). Should A care about the fact that there exists a base class that implements some template logic, inherited by its descendants

The answer is up to you. If A must really care, if A must narrow its input parameters to classes with some sealed logic, abstract or even concrete classes must be present at the signature of method a(...), because interfaces don't guarantee anything

On the opposite, if A doesn't care at all about how the hierarchy is organized, a good idea is to extract the interface with the public methods of the hierarchy, declaring the A.a(...) as receiving this new interface in order of not limiting, in some future, arguments with alternative implementations

Depending of the phase in the project you are, you could not know exactly whether A must care or must not. What I do in the early design is consider everything as interfaces (that is, putting no limits) until being more sure. Normally at the end of design I have more information and confidence around the decision to take

I found an article which presents typical scenarios with their corresponding suggestions:

http://msdn.microsoft.com/architecture/default.aspx pull=/library/en-us/vbcon/html/vbconabstractclassesversusinterfaces.asp


PostPosted: Architecture General, abstract vs interface Top

Sounds like you need interfaces. However, depending on the nature of the problem you are trying to solve, the strategy pattern may be applciable (see Design Patterns by GoF).

This defines the method to execute the strategy as an abstract class and you then implement different strategies (algorithms) as you need them.

An example of this design pattern in the .Net framework are readers. A base strategy is Reader. Specialisations are TextReader, XmlReader etc.

I also used the strategy pattern in a recent project when I needed to download data from an external suppliers web site. The external supplier could change. Also the mechanism to obtain dta could change. For example, one supplier may have a web service, another may use Ftp.

I implemented a base class that had an execute method. Then I created specialisations for each supplier. This enabled me to change the algoritm to download fom the supplier with minimal impact on the rest of the application.

Hope this helps.

Udi Dahan The Software Simplist

PostPosted: Architecture General, abstract vs interface Top

On a side note, deep class hierarchies are not generally recommended. Inheritance in essence breaks encapsulation. One level deep you can probably manage this. More and you might be digging your own grave. Just a thought.


PostPosted: Architecture General, abstract vs interface Top

In my example shown in O/R Mapping thread (http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=543039&SiteID=1), I think Abstract class is more appropriate than interface.

I like to discuss with example. Suppose we have the following requirement:

1. All staff have the same method of CommissionCalculation.

2. Different staff have different AnnualLeaveCalculation.

In Abstract class, we can make a fully implemented method (Not overridable method) called CommissionCalculation and a MustInherit Method called AnnualLeaveCalculation. Initially, we have only FullTimeStaff and PartTimeStaff and implement everything correctly. Two years later, the company introduces a new staff type called OverseaStaff. The programmer (may not be the one originally designing the abstract class) uses the abstract class to create this new class will get a very clear signal, i.e. he does not need to (and cannot) implement or override CommissionCalculation Method but he need to implement AnnualLeaveCalculation Method.

In the case of Interface, the programmer can only implement all methods from scratch. He might implement a wrong CommissionCalcuation for OverseaStaff.

Diego Dagum

PostPosted: Architecture General, abstract vs interface Top

Valuable words, Udi. Thanks so much for the reminder

In effect, reusability by subclassing is offen referred as "white-box reuse" while reusability by composition is "black-box reuse"

GoF established, with respect of this, a golden rule: "favor composition over inheritance"

As you suggest, that doesn't imply avoid inheritance at all but be conscius about broken encapsulation

Good point