Last post Jul 25, 2013 02:46 PM by gerrylowry
Jul 25, 2013 01:41 PM|ramll|LINK
I know we cannot instantiate Abstract class.
Can we Instantiate Interface ? If not, why.. and what are main difference between abstract and interface in implementation.
Jul 25, 2013 01:53 PM|Nasser Malik|LINK
I guess this is a very good reply by Kuschke
A good way to distinguish between a case for the one or the other for me has always been the following:
1. Are there many classes that can be "grouped together" and described by one
noun? If so, have an abstract class by the name of this noun, and inherit the classes from it. (A key decider is that these classes share functionality, and you would never instantiate just an
Animal... you would always instantiate a certain kind of
Animal: an implementation of your
Animal base class)
and Dog can both inherit from abstract class
Animal, and this abstract base class will implement a method
void Breathe() which all animals will thus do in exactly the same fashion. (I might make this method virtual so that I can override it for certain animals, like
Fish, which does not breath the same as most animals).
2. What kinds of verbs can be applied to my class, that might in general also be applied to others? Create an interface for each of these verbs.
Example: All animals can be fed, so I will create an interface called
IFeedable and have Animal implement that. Only
Dog and Horse
are nice enough though to implement ILikeable - I will not implement this on the base class, since this does not apply to
As said by someone else's reply: the main difference is where you want your implementation. By creating an interface, you can move your implementation to any class that implements your interface.
By creating an abstract class, you can share implementation for all derived classes in one central place, and avoid lots of bad things like code duplication.
There is alot more help on internet for
Interface Vs Abstract
Jul 25, 2013 01:55 PM|DarrenJMcLeod|LINK
You can only implement an interface because an interface doesn't have any code it is just the property and/or method signatures. The main difference between an abstract class and an interface is that an abstract class can have code in it. Here is a really
good article on more of the differences: http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface
Jul 25, 2013 01:58 PM|PatriceSc|LINK
No, an interface is about *what* can be done. You'll always need to instantiate an object that "implements" this interface (that is that defines *how* the features provided by this interface should be done).
See http://msdn.microsoft.com/en-us/library/scsyfw1d(v=vs.71).aspx for some considerations about choosing to use an interface or an abstract class...
Jul 25, 2013 01:59 PM|Rion Williams|LINK
Abstract classes will allow you to insert basic functionality and methods (implementation details) within your actual classes unlike Interfaces which will not (so abstract classes can ultimately reduce the amount of code that you may have to
There really is no always use one or always use the other and it is almost completely up to the preference of the developer and the needs that he or she needs to make (most of these decisions will come from future inheritance as both of these are heavily
involved in being derived from).
If you needed to implement functionality that a ton of your classes would share such as a specific property or method and the implementation would be the exact same for all of them, then you would want to use an abstract class. However, if you wanted each
of the classes to have a method or property but allow each of them to provide their own implementation for it (similar to that of a blueprint) then an interface may be a better choice.
I'd strongly encourage you to check out some of the links provided below which discuss when to use one over another like these :
Jul 25, 2013 02:46 PM|gerrylowry|LINK
if you have a Pluralsight membership, Jeremy Clark has an excellent course called c# interfaces released this July.
Jeremy Clark gives some very good examples as to when to consider using interfaces versus abstract classes and also includes examples with concrete classes to round out the picture.
interfaces are fragile and Jeremy Clark shows how to deal with this fragility ... see "interface segregation prinicple" via Google and/or your favourite search engine, for example
FWIW, one advantage of abstract classes is that they can contain implementation code, as well as fields, contructors, and destructors.
"Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries", Second Edition, Krzysztof Cwalina; Brad Abrams; Addison-Wesley Professional, October
22, 2008; Print ISBN-10: 0-321-54561-3, Print ISBN-13: 978-0-321-54561-9, Web ISBN-10: 0-321-54567-2, Web ISBN-13: 978-0-321-54567-1, Pages in Print Edition: 480
classes are the preferred construct for exposing
The main drawback of
interfaces is that they are much less flexible than
classes when it comes to allowing for evolution of APIs. After you ship an
interface, the set of its members is fixed forever. Any additions to the
interface would break existing types that implement the
A class offers much more flexibility. You can add members to
classes that have already shipped. As long as the method is not
abstract (i.e., as long as you provide a default implementation of the method), any existing derived
classes continue to function unchanged.
note: while the book is mainly applicable to designing API's, much of its information is also applicable generically.