Interface vs. Abstract

So, obviously, the next logical question would be when to use Interface and when to use Abstract.

I understand some of the differences between the two like abstract classes can have BOTH implementation and definitions, whereas interfaces cannot do implementation. abstract classes are inherited whereas interfaces are implemented.

Besides that, abstract and interface seem to serve the same purpose.

So, when do I use "abstract" and when do I use "interface"?

Thanks!!
infotechelgAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jens FiedererTest Developer/ValidatorCommented:
When you have some methods you can give your inheritors "for free", you can create an abstract class with those methods, and inheritors do NOT have to implement those methods.  Interfaces don't get "bonus" methods.

When you expect somebody to have to use more than one interface, Interface is really the only option in C#, because C# doesn't support multiple inheritance.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
anarki_jimbelSenior DeveloperCommented:
About purpose - not exactly. I just don't want to repeat myself but have a look at my post in your another thread, about IComparable. Abstract classes are not so useful here. Honestly, in my practice I use interfaces much more often than abstract classes.

http://www.experts-exchange.com/Programming/Languages/C_Sharp/Q_26922834.html
0
anarki_jimbelSenior DeveloperCommented:
Why abstract classes might be better than interfaces:

In interfaces we declare method signatures only. Say, what if you want some predefined (implemented) functionality that you create on a base of interface or abstract class? In this case you may put some implementation into some methods of an abstract class and leave other methods unimplemented, for user to implement.

One more good use of interfaces. Might be not easy to explain :) In .Net solutions we cannot have circular references between projects. I.e., if we have project A and project B in our solution, A may have a reference to B, but B cannot reference A!. That's obvious. But sometimes you need to access A from B... What to do here? Create a third project, say C, for interfaces only, e.g. A and B have references to C.  B cannot see A, but if a class (object) from A implements an interface from C - you can acces this object using interfaces.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

käµfm³d 👽Commented:
Besides that, abstract and interface seem to serve the same purpose.

Well not really, otherwise we'd have one mechanism, not two!!!

You would use abstract classes when you want to have inheritance (which would be dictated by your design) and there is some functionality that needs to be implemented by a child class(es), but along the inheritance chain, a child may not have all the necessary details to implement the functionality.

Here is a new attempt at a real-world example.

Let's say we work for a shipping company, VPS. At VPS we have a base class called Vehicle. Vehicle is used as a foundation for specific types of shipping vehicles we use at VPS, which include: Van, TractorTrailer, Airplane. We also have different kinds of vans, but for simplicity, we'll only see "Sprinter Van". At VPS, all our vehicles have a vehicle identification number. We can define this in our base class since all vehicles have this. Also, our vehicles travel, obviously. We would like to keep track of how far our vehicles go for maintenance reasons.

Vehicle Base
abstract class Vehicle
{
    public abstract double GetMilesTravelled();

    public string VehicleID { get; set; }
}

Open in new window



Van Base
abstract class Van : Vehicle
{
    public abstract override double GetMilesTravelled();
}

Open in new window



Sprinter Van
class SprinterVan : Van
{
    private double _odometer;

    public override double GetMilesTravelled()
    {
        return this._odometer;
    }
}

Open in new window



TractorTrailer
class TractorTrailer : Vehicle
{
    private double _odometer;

    public override double GetMilesTravelled()
    {
        return this._odometer;
    }
}

Open in new window



Airplane
class Airplane : Vehicle
{
    private double _odometer;

    public override double GetMilesTravelled()
    {
        return this._odometer;
    }
}

Open in new window



As demonstrated above, all of our child classes are Vehicles. As such, each has an Odometer. Van doesn't have the necessary details to provide odometer information. By this design, it is left up to the classes which implement Van, namely SprinterVan. All of our other classes provide implementation details for the abstract members of Vehicle.

Most of the time, during your design, it will probably make more sense to use abstraction vs. inheritance. Everyone sees the world differently; as such, everyone will make their own interpretations about objects and concepts. Where you may view all vehicles as objects which move under their own power, I may view all vehicles as objects which have wheels and transport people. Subsequently, each of us may design our Vehicle classes totally differently.

I will say this, I would lean more towards the "is a/has a" side of things when attempting abstraction. A shipping box is the implementation of the abstract concept Box. A shipping box probably has postage on it. However, a postcard also has postage on it. You use a shipping box to send things through the mail. You use a postcard to send data through the mail. A postcard is NOT a box, yet they both could be seen as implementing the IPostage interface below:

interface PostageRate
{
    double PostageRate { get; set; }
}

Open in new window


Don't take these example as the mold by which all abstract classes are created. As I said previously, most of your decisions to use abstraction over interfaces and vice-versa will be based on your design. There are certainly other ways I could have defined the above classes: the odometer is common to all vehicles, so we could store it there too. Of course, what if we later added a vehicle that didn't have an odometer? What if we started having bicycle couriers? This is just one example of how, based on my chosen design, abstraction could be used.
0
käµfm³d 👽Commented:
I don't deny that the lines between interfaces and abstract classes are kind of gray. There are times when you can achieve the same functionality by using either mechanism.
0
käµfm³d 👽Commented:
Most of the time, during your design, it will probably make more sense to use abstraction vs. inheritance.

Well that didn't make one bit of sense, did it? What I meant to say was, "... it will probably make more sense to use interfaces vs. abstraction."


And for this one, I must have been tired...


interface IPostage   // Not PostageRate  : \
{
    double PostageRate { get; set; }
}

Open in new window

0
infotechelgAuthor Commented:
So, it seems to me that interfaces and abstracts are best used when you are writing code that other people may use and implement in their own environments.

Am I right by saying that or am I way off base?

For me, I'm an in-house developer for a company who doesn't share code with anyone. Though, I'm still trying to learn.
0
Jens FiedererTest Developer/ValidatorCommented:
Right, but everybody shares code with somebody these days, even if only on the receiving end.  Microsoft shares their library code with you, and you AT LEAST need to be able to use the interfaces and abstract classes that THEY define.

Coming up with your own interfaces and abstract classes is not STRICTLY necessary all the time, it's not really something for the complete beginner, but you will probably want to do it eventually even if only to make reusing your own code easier.
0
käµfm³d 👽Commented:
For me, I'm an in-house developer for a company who doesn't share code with anyone.

Not even with the other in-house developers?
0
infotechelgAuthor Commented:
@kaufmed

There's one other developer and we work on different projects.
0
Jens FiedererTest Developer/ValidatorCommented:
The original question was thoroughly addressed.

Unresolved is the question of whether the author personally should be using these constructs, and that is for the author to answer - we have given him the considerations that need to be applied for that decision.
0
Jens FiedererTest Developer/ValidatorCommented:
I'd suggest a split between 35264937, 35265623, and 35267123 (all experts commenting, everything was relevant).
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C#

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.