Difference Between Interface and Abstract Class

  • Thread starter Thread starter msbs1984
  • Start date Start date
Hi,

That is the same as an image of a chick and an egg (for vb a scrambled egg).

(An Interface shows the contract how a class should look, an abstract class
(the name in VB is mustinherit) is a real class, however you have always to
inherit it).



Cor
 
msbs1984 said:
Difference Between Interface and Abstract Class?
Click to expand...

In addition to Cor,

If there is no common code and no common fields (=class level variables) of
all classes that would inherit from an abstract class, declare an interface
instead.


Armin
 
In addition to Cor,

If there is no common code and no common fields (=class level variables) of
all classes that would inherit from an abstract class, declare an interface
instead.

Armin
Click to expand...

In addition to Cor and Armin,

Remember that a class can only inherit a single class, but can
implement any number of interfaces. For that reason I normally try to
use interfaces unless there is absolutely a terrific reason to use an
abstract class. It allows me more flexibility if a project is re-
purposed (of course we know no managers would ever change a project's
design mid way through...)

By the Cor, I like the "(for vb a scrambled egg)" line. :-)

Thanks,

Seth Rowe
 
msbs1984 said:
Difference Between Interface and Abstract Class?
Click to expand...


'MustInherit' classes can contain implementation code whereas interfaces are
just interfaces.
 
Difference Between Interface and Abstract Class?
Click to expand...

They're used for different purposes and different reasons:

Interface usage example:

I have a dll with, say, 10 different classes, each one does something
totally different than the rest. (Actual app was communication
decoding, needed to be able to decode several different communications
protocols, created a separate class for each one.)

I wouldn't know until run time which of these classes I had to use.
(The app called a dll which read a config file which told the dll
which protocol class to load.)

Since I didn't know until run time which class to use, I couldn't
declare a specific class instance. (I could have had some branching
code in the app but then I'd have to recompile and reinstall every
time I wanted to add a new protocol in the future. More on this
later.)

I declared an interface and the interface was the "face" that all
these classes presented to the app.

I did not want the app to be aware of or have to deal with these
different classes, so I just declared an object variable as though it
were going to be an instance of the interface just like it was a
class.

Elsewhere, I created an instance of the appropriate class and passed a
referrence to the interface object variable.

Meanwhile, the app dealt with just the interface, never knowing what
was behind the interface. Regardless of what actual class instance
was "plugged into" the other side of the interface, the same face was
always presented to the app.

Abstract Class Example:
In the above app, the 10 decoding classes actually shared quite a bit
of common logic. So first I created an abstract class that
implemented the interface and also implemented all the common logic.
Then I created the 10 classes, each one inheriting the base class
already containing all the common logic and interface, and then
finally implemented unique decoding logic in each of the classes.

Another interface example:
In later generations of this app, I wanted to be able to upgrade and
add decoding modules to an installed copy of the app later without
having to recompile and reinstall the entire app every time I wanted
to add a new protocol. (Essentially I wanted to be able to add more
communications drivers in the future just by copying in a new dll with
the new protocol.)

So again, the main app just dealt with the interface and never knew
where the actual class instance that did the decoding came from. A
separate dll read a config file, some info in the config file told the
dll whether the protocol to use would be found in one of the compiled
classes or in a new driver dll that had been copied in, the name of
the new dll, and the name of the class in the dll to use. The dll
would open the new driver dll, create an instance of the desired
decoding class and pass it back to the interface object variable owned
by the app. The app never knew nor cared where or how the actual
class instance came from. All it had to deal with was the same
interface regardless of where or how the actual class instance got
there.
 
Difference Between Interface and Abstract Class?
Click to expand...

Just another less-than-obvious difference is that adding a member to
an interface breaks version compatibility whereas adding a member to
an abstract class does not.

Brian
 
Brian,
Just another less-than-obvious difference is that adding a member to
an interface breaks version compatibility whereas adding a member to
an abstract class does not.
Click to expand...

If you add an abstract method to a class it will break existing
derived classes.


Mattias
 
Back
Top