Abstract Classes vs Interfaces

Which one to choose when?

Page 1 of 1

3 Replies - 654 Views - Last Post: 11 September 2010 - 10:35 AM Rate Topic: -----

#1 Guest_Jason*


Reputation:

Abstract Classes vs Interfaces

Posted 11 September 2010 - 05:05 AM

Hello everybody,

While reading through articles on the Internet and reading through my c# books. Here is what the differences are that I have read about:

A class marked as abstract it may define any number of abstract members to provide a
polymorphic interface to all derived types. However, even when a class does define a set of abstract members, it is also free to define any number of constructors, field data, nonabstract members (with implementation), and so on. Interfaces, on the other hand, only contain abstract member definitions. The polymorphic interface established by an abstract parent class suffers from one major limitation in that only derived types support the members defined by the abstract parent. To overcome this, we use interfaces


However, I always find myself using Interfaces over abstract classes in every situation. This leads me to believe that I do not full understand the concepts.

I would really like to hear about the methods that some experienced programmers use to choose between the two. I would also appreciate some examples in which one is very definately preferable to the other, if possibe please.

Thank you very much everyone.

Is This A Good Question/Topic? 0

Replies To: Abstract Classes vs Interfaces

#2 macosxnerd101  Icon User is online

  • Self-Trained Economist
  • member icon




Reputation: 10443
  • View blog
  • Posts: 38,679
  • Joined: 27-December 08

Re: Abstract Classes vs Interfaces

Posted 11 September 2010 - 10:09 AM

Abstract classes are for a strong inheritance relationship. If you have an abstract GeometricObject class with abstract methods getArea() and getPerimieter(), you may have subclasses Circle, Rectangle, Triangle, etc. Note how they are all closely related. The other benefit of abstract classes is that you can define it otherwise normally as a class without having to reinvent the wheel each time you extend it. The same cannot be said for interfaces, as they cannot have constructors, fields, etc.

Interfaces, however, are for classes that aren't related. For example, you may have an Edible interface, with Chicken, Lobster, and Salad all as implementing classes. Other than all being Edible, I wouldn't put them in the same categories or otherwise relate them via a class-inheritance relationship. So the interface provides a loose relationship.
Was This Post Helpful? 3
  • +
  • -

#3 KYA  Icon User is online

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3101
  • View blog
  • Posts: 19,140
  • Joined: 14-September 07

Re: Abstract Classes vs Interfaces

Posted 11 September 2010 - 10:12 AM

Or, to put that all information from my esteemed colleague into a single sentence, use abstract classes when you need base functionality.
Was This Post Helpful? 2
  • +
  • -

#4 Guest_Jason*


Reputation:

Re: Abstract Classes vs Interfaces

Posted 11 September 2010 - 10:35 AM

Thanks you very much; both of you. That is exactly what I was looking for. A black and white criteria I can use to decide which to use.

Thnaks you again!
Was This Post Helpful? 0

Page 1 of 1