0

Possible Duplicate:
Interface vs Abstract Class (general OO)

I can see their advantage in coordination of a developing team, or code that might be further developed by others.

But if not, is there a reason to use them at all? What would happen if I omit them?

Abstract – I'll be able to instantiate it. No problem. If it doesn't make sense – I won't.

Interface – I have that functionality declared in all classes deriving from it anyway.

Note: I'm not asking what they are. I'm asking whether they're helpful for anything but coordination.

Community
  • 1
  • 1
ispiro
  • 26,556
  • 38
  • 136
  • 291
  • @KirkWoll I took a look at it, but didn't see any answer to my question. – ispiro Apr 04 '12 at 18:13
  • I do not see how your question covers any ground not travelled by the answer to that question. – Kirk Woll Apr 04 '12 at 18:15
  • @KirkWoll They're explaining what interface and abstract _are_. But that seems to be useful only for coordination. I'm asking if there is any _other_ advantage to them. – ispiro Apr 04 '12 at 18:18
  • @ispiro Actually the main answer do explain what are the main differences/advantages. For example, one of the biggest disadvantages of using abstract classes is that your subclasses can only inherit from one of them. There are a lot of more similarities and differences. Check out this link: [Abstract Class versus Interface](http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface) – Paolo Moretti Apr 04 '12 at 19:18
  • @PaoloMoretti A) I'm not asking what the differences between them are, just as I'm not asking what they are. B) I'm not asking what their advantages are. C) I _am_ asking whether they have an advantage when not in the realm of coordination. – ispiro Apr 04 '12 at 19:33

4 Answers4

2

Both are what I call contracts and can be used in the following fashion by an individual developer:

Abstract

  • Allows for polymophism of differing derived implementations.
  • Allows one to create base functionality which can be dictated or not that the derived class be required to implement.
  • Allows for a default operation to be runtime consumed if the derived does not implement or required to implement.
  • Provides a consistency across derived objects which a base class pointer can utilize without having to have the actual derived; hence allows generic operations on a derived object from a base class reference similar to an Interface in runtime operation.

Interface

  • Allows a generic pattern of usage as a defacto contract of operation(s). This usage is can be targetted to the process in hand and allows for the surgically precise operations for that contract.
  • Used to help with factory patterns (its the object returned), mocking of data during unit tests and the ability to replace an existing class (say from a factory returning the interface) with a different object and it doesn't cause any consumer of the factory any pain of refactoring due to the adherence of the interface contract.
  • Provides a pattern of usage which can be easily understood away from the static of the rest of the class's implementation.

Long story short are they required to get a job done? No.

But if you are into designing systems which will have a lifespan of more than one cycle, the upfront work by said architect will pay off in the long run whether on a team or by an individual.

++Update

I do practice what I preach and when handing off a project to other developers it was nice to say

  1. Look at the interface IProcess which all the primary business classes adhere to. That process defines a system of goals which can help you understand the purpose and the execution of the business logic in a defined way.
  2. While maintaining and adding new functionality to the project the interfaces actually helped me remember the flow and easily add new business logic into the project.
ΩmegaMan
  • 29,542
  • 12
  • 100
  • 122
1

Abstract - you can instantiate a child of it, but what is more important, it can has its own non abstract methods and fields.

Interface - more "rough" one in regard of abstract, but in .NET you can have multiple inheritance. So by defining interface you can lead consumer of your interface(s) to subscribe to different contracts(interfaces), so present different "shapes" of specified type.

Tigran
  • 61,654
  • 8
  • 86
  • 123
1

I think if you're not coordinating with others, it does two things

  1. helps keep your from doing weird things to your own code. Imagine your write a class, and use it in multiple projects. You may evolve it in one project so that it is unrecognizable from it's cousin in another project. Having an abstract class or interface makes you think twice about changing the function signatures.
  2. it gives you flexibility going forward - plenty of classic examples here. Use the generic form of the thing you're trying to accomplish, and if you decide you need a different kind later (streamreaders are a great example, right?) you can more easily implement it later.
Aerik
  • 2,307
  • 1
  • 27
  • 39
0

There are many reasons to use either construct even if you are not coordinating with anyone. The main use is that both actually help express the developper intent, which may help you later figure out why you choose the design you actually chose. They also may allow for further extensibility.

Abstract class allow you to define one common implementation that will be shared across many derived classes while delegating some of the behavior to the child classes. It allows the DRY (don't repeat yourself) principle to avoid having the same code repeated everywhere.

Interfaces expresses that your class implements one specific contract. This has a very useful uses within the framework, among which:

  • Use of library functionality that necessitate the implementation of some Interface. Examples are IDisposable, IEquatable, IEnumerable...

  • Use of constraints in generics.

  • Allow mocking of interfaces (if you do unit testing) whithout having to instanciate a real object.

  • Use of COM objects

Vincent Hubert
  • 1,386
  • 9
  • 23
  • Your four points above: it seems that three have to do with coordination, and as for unit testing – why would an interface be less work than instantiating an object? Am I missing something here? – ispiro Apr 04 '12 at 18:43
  • If your class implements the IDisposable interface, it can be used into a using( ) statement. It has nothing to do with coordinating with other developper, it helps automatically manage resource disposal. – Vincent Hubert Apr 04 '12 at 19:01
  • I meant coordination between the .NET development team and myself. They created `IDisposable` in order to coordinate with me. – ispiro Apr 04 '12 at 19:06
  • Well, if you see "using the .Net framework and features of the C# language" as "coordinating with the .Net development team", a lot of things can be classified as coordination. :) Mocking an interface will save you calls to class constructors (and their base classes) – Vincent Hubert Apr 04 '12 at 19:29