On Oct 2, 6:37 am, "msbs1984" <u37888@uwewrote:
Difference Between Interface and Abstract Class?
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.
