Any could you please explain me the above with scenarios..

Herbie

public abstract class Foo
{
   public abstract void Bar();
}

There's no default implementation for any method to be found in that example.

The truth is, if we had multiple inheritance there would be no reason to use interfaces. But we don't. So, in general it's best to define an interface first. Then you might want to provide an abstract class to help with implementing the interface.

I usually use abstract classes if I have a default implementation of one or more methods. If not, I'll stick with an interface.

I did a quick Bing learning and here is a simple article.

http://www.techotopia.com/index.php/Understanding_C_Sharp_Abstract_Classes

I am pretty sure you cannot use virtual method in an interface, which sets apart from abstract class.

Here is a quick comparison

http://en.csharp-online.net/Should_I_use_an_abstract_class_or_an_interface%3F

Meaning, if you want multiple inheritance, interface only. C# is still single inheritance where abstract class cannot be instantiated.

Pros on abstract, versioning, read the link. Cons, single inheritance obviously.

20 minutes ago, magicalclick wrote

I am pretty sure you cannot use virtual method in an interface, which sets apart from abstract class.

All methods in a interface are virtual.

The fact that methods/properties on an interface aren't virtual/abstract is important to note because if they were you'd be able to override them when you inherit from a class that implements the interface. You can't, unless the implementation declares the method/property to be virtual/abstract.

1 hour ago, wkempf wrote

@spivonious: You can't ignore the elephant in the room. You can implement multiple interfaces, you can inherit only one class (abstract or not).

True, but that's not a rule across platforms. C++ lets you do it, for example. .NET and Java don't.

1 hour ago, wkempf wrote

@Richard.Hein: *sigh* No, no methods on an interface are virtual. The terms "virtual" and "abstract" apply only to classes. For that matter, @magicalclick is just as wrong when he says "if you want multiple inheritance, interface only", because you don't inherit interfaces. You implement them. Right now I may sound like a grammar *, but most of the confusion surrounding these topics comes from incorrect usage of terms such as these.

The fact that methods/properties on an interface aren't virtual/abstract is important to note because if they were you'd be able to override them when you inherit from a class that implements the interface. You can't, unless the implementation declares the method/property to be virtual/abstract.

Hmm ...

interface IFoo{    void Bar();}

ILDASM:

.method public hidebysig newslot abstract virtual

        instance void  Bar() cil managed

{

} // end of method IFoo::Bar

Abstract and virtual.  Well, you made me doubt myself enough to check.

Abstract classes are something of a more pure OOP ideal and fit better with a design that heavily leverages polymorphism, but such designs tend to be over-architected and unnecessary. By contrast Interfaces are a much looser concept that is a little less purist from an OO perspective but generally lends itself to less complex and more flexible designs.

If you generalize to an interface, you're writing code that does not enforce a single class hierarchy or any class hierarchy for that matter.

Since abstract classes and interfaces aren't mutually exclusive, you can use both. Use an interface to enforce consistency of method signatures and then abstract classes to enforce a particular lineage of class hierarchy.

11 hours ago, wkempf wrote

@Dr Herbie: Sorry, that's not correct, nor does it explain why to use one over the other.

1 2 3 4

public abstract class Foo {    public abstract void Bar(); }

There's no default implementation for any method to be found in that example.

But what is the purpose of code like that?  Why would you make it abstract and not an interface?

If I saw that in live code I would change it to an interface.

I get what you mean about multiple inheritance. In C++ I would have used a pure abstract class with no implementation instead of an interface because I never liked to use multiple inheritance with real implementations in the base class. I was so glad that C# didn't allow it.

Herbie

class Program
{
    private interface IVehicle
    {
        void Move();
    }

    private abstract class Car : IVehicle
    {
        public abstract void Move();

        protected void Drive(string name)
        {
            Console.WriteLine("Drive " + name);
        }
    }

    private class Toyota : Car
    {
        public override void Move()
        {
            Drive("Toyota");
        }
    }

    private class Ford : Car
    {
        public override void Move()
        {
            Drive("Ford");
        }
    }

    private abstract class Bicycle : IVehicle
    {
        public abstract void Move();

        protected void Peddle(string name)
        {
            Console.WriteLine("Peddle " + name);
        }
    }

    private class Cannondale : Bicycle
    {
        public override void Move()
        {
            Peddle("Cannondale");
        }
    }

    private class Bianchi : Bicycle
    {
        public override void Move()
        {
            Peddle("Bianchi");
        }
    }

    private static void MoveDownStreet(List<IVehicle> vehicles)
    {
        Console.WriteLine(String.Empty);
        Console.WriteLine("Move IVehicles down the street");
        vehicles.ForEach(v => v.Move());
    }

    private static void MoveDownLeftLane(List<Car> cars)
    {
        Console.WriteLine(String.Empty);
        Console.WriteLine("Move Cars down left lane");
        cars.ForEach(c => c.Move());
    }

    private static void MoveDownBikeLane(List<Bicycle> bikes)
    {
        Console.WriteLine(String.Empty);
        Console.WriteLine("Move Bicycles down bike lane");
        bikes.ForEach(b => b.Move());
    }

    static void Main(string[] args)
    {
        var allvehicles = new List<IVehicle>();
        allvehicles.Add(new Toyota());
        allvehicles.Add(new Ford());
        allvehicles.Add(new Cannondale());
        allvehicles.Add(new Bianchi());

        MoveDownStreet(allvehicles);
        MoveDownLeftLane(allvehicles.Where(v => v.GetType().BaseType == typeof(Car)).Cast<Car>().ToList());
        MoveDownBikeLane(allvehicles.Where(v => v.GetType().BaseType == typeof(Bicycle)).Cast<Bicycle>().ToList());
    }
}

From a pure OO perspective an abstract class represents an "is a" relationship wheras an interface is more of a "can behave like a" relationship.

Whereas I tend to think of interfaces as 'shapes'.  Any instance that has that 'shape' can be used by code that is coded against the 'shape' of the interface (the I in SOLID).

So is an abstract class is 'is a', then an interface is a 'looks like a'

Herbie

Interfaces describe a behaviour, rather than what the thing is. To use the age-old drawing example, you would have an (abstract) base class "Shape" (because that's what circles and triangles and whatever are), but if you were to create an interface it'd be something like "IDrawable" because that's what they can do: they are things that can be drawn. You could even have an abstract Shape class that implements the IDrawable interface (but leaves its concrete implementation up to the derived classes).

It's not a coincidence that so many of the .Net BCL interfaces have names ending in "able".

Herbie

4 hours ago, AndyC wrote

@cbae: That's a really hideous mix of interfaces and abstract classes though.

From a pure OO perspective an abstract class represents an "is a" relationship wheras an interface is more of a "can behave like a" relationship.

No sh1t, genius. I wrote that code specifically to show that the two mechanisms aren't mutually exclusive. It also showed the two different purposes of one vs. other. Continuing with Sven's point, in my "hideous" example, the interface is used for when your only concern is whether or not an object "can do" (i.e. that the object can "move down the street") without any concern for WHAT IT IS. The abstract class was used for when you are concerned about what it is (i.e. only cars can travel down the left lane and only bicycles can travel down the bike lane). So I would say Sven is absolutely correct.

Abstract class -> reference type

Use abstract classes when you are creating a framework (wpf or something).

Use interfaces when creating large applications wich require dependency injection.

17 minutes ago, Maddus Mattus wrote

Interface -> value type

I'm not entirely sure if you're trying for an analogy or if you're being literal here, but in case of the latter, you're wrong. Interfaces are not inherently tied to either reference or value types (both can implement an interface), but they're mostly treated like reference types. For instance, if you cast a variable of a value type to an interface type, it will be boxed.

@Surendiran: the problem is that there is no definite example of that. As with most things related to design, the answer is "it depends" most of the time.

On the boundry of systems you should use interfaces, as they act as contracts. Abstract classes are less suitable for these tasks, because they may have logic or dependencies on the system. A interface is a clean cut, where abstract classes may still have ties. In the system itself, when it adds value you can use abstract classes.

I am taking a training and i have to give some real time example...please help

Herbie

just like the linked I posted said,

Once you define an Interface and start to use it in many other classes, you cannot change the interface easily. Because for every new method you added to the existing interface, all the classes that includes the interface has to implement your new method, otherwise it wouldn't compile obviously.

This is mainly because interface (also abstract methods) do not have a default implementation, thus, you have to implement it everywhere.

But, if you use this at base

protected string _modelName = "I am base model";
public virtual string GetModelName() { return _modelName; }

your sub-classes automatically can do GetModelName without any change in code.

of course, they all return "I am base model" if you really do nothing. You can easily add

_modelName  = "I am newer model";

in the constructor to make it meaningful. If you don't this, it is only silly, but, the code is definitly fine. Of course, the not so silly example would be adding a timestamp, which you really don't need to change anything to sub-classes.

Interfaces are purely abstract and guarantee member invariance, by definition. As Sven mentioned, they represent "can do" or an invariant contract that specifies "can do and will always do as expected to do", to be precise. Once an interface is defined, that's it. You must never change it's member signatures. Ever.

Abstract classes, on the other hand, are classes that can be purely abstract (like an interface), can't be instantiated like a non-abstract class, and must be inherited (VB makes this characteristic obvious with the MustInherit modifier versus C#'s abstract, which is arguably a more abstract way  of expressing that a class must be used as a base class, can't be instantiated and doesn't need to possess any implemented members or can provide full member implementations).

So, for example, if you want to be able to make changes to the implementations of some abstract type's members without breaking current consumers, you use an abstract class. If you want to guarantee that a type conforms to an invariant abstract functional specification ( ), use an interface. In other words, abstract classes are useful for component versioning (you can change their implementations without changing the definition of the class).

At any rate, enough of my rambling. Here's what MSDN says ( and it's right )

===========================================================================

Here are some recommendations to help you to decide whether to use an interface or an abstract class to provide polymorphism for your components.

• If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
• If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
• If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
• If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

C

@Sven : Thank you, I edited my post

class Blah :
Allow Inheritance For Assembly;
Deny Inheritance, Instantiation For All

{

}

I think this would be similar to "internal abstract"?

Visual Basic is incorrect in calling NoInherit and MustInherit keywords, as I always think that they are not single words, it is a case of comparing apples to orangelemons which is unfair.

Although it's weird that they didn't split them in VB, as VB has plenty of two-word keywords, like "For Each" or "End For/While/Sub/Function". Even C# has at least one two-word keyword: "yield return" (yield is not a keyword by itself, and can be used as an identifier).

// Looping over a list.
let list1 = [ 1; 5; 100; 450; 788 ]
for i in list1 do
   printfn "%d" i

I have to keep up with WPF, WCF, Silverlight, SQL Server, SSIS, SSAS, EF, WF, WCF Api, OData, WCF Dataservices, Prism, MVVM, Wndows Azure, WP7, ASP.Net, Rx, LINQ, PLINQ, ASP.Net MVC, HTML5, jQuery, javascript, C# etc etc etc,..

So FRIKKEN sue me if I forget how to do a FRIKKEN foreach loop!

var enum = list.GetEnumerator();
while(enum.GetNext())
{

}

Did I pass?

for( int value : list )
    System.out.println(value);

5 hours ago, Maddus Mattus wrote

I am lost without intellisense,..

I have to keep up with WPF, WCF, Silverlight, SQL Server, SSIS, SSAS, EF, WF, WCF Api, OData, WCF Dataservices, Prism, MVVM, Wndows Azure, WP7, ASP.Net, Rx, LINQ, PLINQ, ASP.Net MVC, HTML5, jQuery, javascript, C# etc etc etc,..

So FRIKKEN sue me if I forget how to do a FRIKKEN foreach loop!

1 2 3 4 5

var enum = list.GetEnumerator(); while(enum.GetNext()) {   }

Did I pass?

LOL, no, there's no GetNext, it's MoveNext + Current. 

The tenet that terseness trumps readability in language design was a great concept in the '70, when you had to type every single character in your program (and possibly getting it punched in a card). Maybe it's high time we reevaluated the whole thing.

thats the common defintion about abstract class and interface...but my question is how to chose either one...on what basis you will go for abstract and interface

16 minutes ago, Surendiran Bala wrote

@Richard.Hein:

thats the common defintion about abstract class and interface...but my question is how to chose either one...on what basis you will go for abstract and interface

OK for me it's as follows

1) Do you have common code which will need inheriting in all classes? Abstract class.

2) Is your functionality exposed outside your assembly? Consider an interface.

3) Will you have multiple things on a single class (for example Readable, Writeable), which could be combined? Has to be an interface.

Made my point exactly, where is my intellisense!

Do I at least get credits for thinking outside the box?

37 minutes ago, blowdart wrote

*snip*

OK for me it's as follows

1) Do you have common code which will need inheriting in all classes? Abstract class.

2) Is your functionality exposed outside your assembly? Consider an interface.

3) Will you have multiple things on a single class (for example Readable, Writeable), which could be combined? Has to be an interface.

Again, interfaces and abstract classes aren't mutually exclusive. So you can start with an interface to expose functionality outside your assembly, and then create an abstract class that implements that interface to have common code for the branch of classes that you would use internally.

1 hour ago, Maddus Mattus wrote

@Richard.Hein: damn,..

Made my point exactly, where is my intellisense!

Do I at least get credits for thinking outside the box?

Ok.    IEnumerable should have a GetNext() anyways. 

That's is why this question has taken three pages and things are evidently still not clear to you, people cannot simply explain experience to you, as in some ways you keep asking what hot or cold are, when you need to get your hands dirty and step up to the plate.

I usually use interfaces for the plugin-like scenario, when I want to offer a way to extend behavior without requiring changes to the code itself. I don't really know of the formal use of an abstract class...it just ends up being a container for redundant code such that it does not have a full enough implementation to stand on its own as an actual type.

EDIT: This is actually similar to what cbae had posted above.

If you design around interfaces you ensure the best decoupling between components, and there are nothing but other interfaces and primitive types exposed.  You'll have maximized the flexiblity of the implementation, while ensuring a stable, long-term contract between the components of your application. 

However, deciding if something should be defined as an abstract class usually happens during implementation (or planning the implementation), when one realizes that a few concrete types (that may or may not share common interfaces), are essentially the same in some way; in a functional sense, not just on the interface, but "inside" where they have similar structures or algorithms.

30 minutes ago, MasterPie wrote

EDIT: This is actually similar to what cbae had posted above.

Mine is too .. which tells me we should abstract out the details of all of these posts that share common implementation details into one base post, see what's left over and derive posts from there ... .

2 hours ago, cbae wrote

*snip*

Again, interfaces and abstract classes aren't mutually exclusive. So you can start with an interface to expose functionality outside your assembly, and then create an abstract class that implements that interface to have common code for the branch of classes that you would use internally.

Oh indeed so. Take something like a file management class; you could start off with IReadable and IWriteable and then implement FileBase which takes both those as an interface. But I'd still be starting with the interfaces.

All the examples for Unity and other IoC containers give you the impression that you have to use interfaces to map to concrete types for the ENTIRE dependency graph. As it turns out, you can just register concrete types (without mapping them to any interface) so that Unity knows to use the concrete type for other dependencies or to build up the dependencies, which may or may not involve type mapping, for that concrete type.

I'm not saying you should avoid using interfaces, but you should definitely consider if there's a good reason to use an interface, and doing so just to shoe-horn an IoC container into your application isn't one of them.

@cbae: Yeah, the decision to use Unity came after I had designed and implemented everything...I just wanted to be able to swap things out without having to recompile.

4 days ago, wkempf wrote

@Richard.Hein: *sigh* No, no methods on an interface are virtual. The terms "virtual" and "abstract" apply only to classes. For that matter, @magicalclick is just as wrong when he says "if you want multiple inheritance, interface only", because you don't inherit interfaces. You implement them. Right now I may sound like a grammar *, but most of the confusion surrounding these topics comes from incorrect usage of terms such as these.

The fact that methods/properties on an interface aren't virtual/abstract is important to note because if they were you'd be able to override them when you inherit from a class that implements the interface. You can't, unless the implementation declares the method/property to be virtual/abstract.

Actually the keywords virtual and abstract apply only to classes. The term virtual is entirely valid, because interfaces are implemented via a vtable through which the call is made.

Also you can override methods of an interface by implementing them explicitly on derived classes for exactly this reason (you shouldn't because that way madness lies, but you can - and one example of where I've seen this happen is re-implementing IDisposable on top of a base class which is itself IDisposable in order that when you down-cast to the base class and it gets disposed, you properly dispose the elements of the derived class as well)

http://www.codeproject.com/Articles/36870/Abstract-Class-Vs-Interface

Why to use each other in place of another??this question is basically wrong, but for curiosity it is d perfect question ,

Abstract classes are classes and interface are nt classes , on of d most im thing is may be we'll get a situation where we have to inherit multiple attributes ,functions ,so we need interface there,

,in a way we can say that Abstract type should be used when we need to imply functions or inherit functions , and interface are for classes , Lets see in a different way ,

Consider i need to define basic functionality so i create a abstract class and let other classes override functions in their own definition, nd I now if i need to create a class which can have attributes and functionality from two different classes i'll use interface,

Like a class Director(This is someone else example from a blog) it has some basic functionality direction management blah blah, and there is a class Actor its main functionality is to act,, Now may be one in a thousand cases there will be a possibility That actor can be a director too so he has his own class methods and attr and it inherits Director Attributes also  ,,so the now created class can have both functionality of an actor class and director class, nw if i create an abstract class than i have to override its functions and i can not inherit two or more than two classes and creating a hierarchical order of Inheritance like Director - -Actor--New actor/Director ....will be a overhead and cause prob, may be some actor doesn't want to be a director , So in short when we Interface are mainly for multiple inheritance abstract are for providing a nearly common functionality,Which interface also allows but in a different way .

well im a very young player in this playground of OOp and .NET ,

Hope im making some sense here ,but i also know that this is not a good formatted view on Interface and Abstract Classes .