Technical reason for using Abstract Classes in C#/Java

Question

According to OOP, Abstract Classes are needed to model those objects that have no existence in the real-world but serves as a base class for several real-world objects.

For Example:

   BankAccount            
       /\
      /  \
     /    \
    /      \
Current     Savings
Account     Account

Here BankAccount should be modeled as an Abstract Class.

But what is the technical reason for using Abstract Classes in C#/Java?link text

For example:

The OOP reason for using Interfaces is to model Behavioral inheritance (Inheritance with no real hierarchical relationship).

The technical reason for using Interfaces in C#/Java is to solve the problem of multiple inheritance (If I am not wrong!).

Answer 1

Abstract classes can't be instantiated because they lack method definitions.

You could define a junk -- do nothing -- method function in the superclass. But that's silly. Rather than define a "do nothing", don't define anything.

With a body missing, the method is abstract. That makes the class as a whole abstract.

---

Why?

Because you don't want to specify a "do nothing" method body. You want to omit the method body entirely, leaving a place-holder to be filled by a subclass.

You create superclasses to contain common behavior among subclasses. In some cases, the superclass cannot be a complete class because each subclass must provide an override or extension.

We provide a abstract superclass because we need subclasses to provide the missing features.

Answer 2

Abstract classes can have default behavior if something sensible is possible; interfaces cannot.

An abstract class can provide default behavior for ALL methods or no methods; developer's choice; interfaces cannot.

Abstract classes can have state that's shared with all subclasses; interfaces don't specify state.

So your abstract BankAccount can have a balance attribute that Savings and Checking can be granted access.

Answer 3

Im not sure I understand your question but, an abstract class cannot be instantiated so it only serves this purpose.

Answer 4

I'll give a real world example. I have an abstract class call cSourceControl. Then I have a class for Visual Source Safe call cVSS and one for Subversion called cSVN, both inherited from cSourceControl.

Now the abstract class has a bunch properties and methods (yes, with code) that the inheriting classes can just use. The abstract class also defines a bunch of abstract methods that an inherited class must implement:

public abstract DataTable getFiles(string path, string filter, DateTime since, bool filterAuthorByLastCheckin, bool expandAll, bool onlySinceBranched);
public abstract DataTable getFiles(string path, string filter, DateTime since, string lastUser, bool filterAuthorByLastCheckin, bool expandAll, bool onlySinceBranched);
public abstract long getFile(string sFileName, string sVersion, string sLocalFileName);
public abstract DataTable getFileVersions(string sFileName);
public abstract DataTable getDirectories(string path, bool expandAll);
public abstract DataTable getChangedFiles(string path);
public abstract DataTable GetFileLogRevision(string path, string revision);
public abstract DateTime getBranchStartDateTime(string sBranch);

From this you can tell that a SourceControl class will need each of these, but the way it looks in cVSS is very different than how it looks in cSVN. Another payoff is that at runtime I can select VSS or SVN. A simplified code snip might be:

cSourceControl sc;

if(usingVSS)
   sc = new cVSS();
else
   sc = new cSVN();

DataTable dtFiles = sc.getChangedFiles("myproject/branches/5.1/");
etc.

Now when my customers start asking for Git or SourceGear, I just have to create those classes and change very little else.