Book a Demo

Author Topic: Interfaces: when to use and why?  (Read 4008 times)

CJ

  • EA User
  • **
  • Posts: 288
  • Karma: +0/-0
    • View Profile
Interfaces: when to use and why?
« on: July 29, 2004, 10:03:23 am »
G'day folks,

I still can't figure out when to use interfaces in class and component diagrams.

If an interface is used to describe the operations that one or more classifiers implement, then why not create an abstract class that the same classifiers can generalize?

Would that not give the same result?  I don't understand (actually, I think I can, but it's "on the tip of my tongue" ... almost have my finger on it) what advantage an interface (realized by classifiers) would have over an abstract class (generalized by classifiers).

Help?
Cheers and best regards.

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Interfaces: when to use and why?
« Reply #1 on: July 29, 2004, 04:05:45 pm »
A couple of points.

1) Interface elements as a design component that are added "late" in the design process.

Interfaces can resolve multiple inheritence designs when the implmentation language doesn't support mulitple inheritence - e.g. c#.

These become physical implementation items - used by the compilers to enforce compliance of classes to the interface "contract".

2) Interfaces as analysis elements in deployment structuring (aka "component based systems")

In these types of models we can use interface elements to specify behavioral compliance of (interchageable) components.  The interfaces are not implementation items but allow compliance checking at the model level.



I am sure there are other more compelling reasons for implementation level interface elements but I'll leave that to those who know more than I.

hth
Bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2919
  • Karma: +55/-3
    • View Profile
Re: Interfaces: when to use and why?
« Reply #2 on: July 29, 2004, 11:41:33 pm »
What a great question for a Friday afternoon!

An abstract class describes the core essence of the sub-classes derived from it; an interface describes what can/must be done. A car is a vehicle that can be steered left or right: define vehicle as an abstract class, steerable as an interface. Then when you want to steer a herd of cattle... :)

If you are given a class that somebody else has created, you can bolt on an interface without touching any of their code. With an abstract class, you would have to perform a major re-design to bolt on the inheritance after the fact.

An abstract class can provide default code, an interface can't. So if you want to add a new method to an interface you will have to track down every implementor in existence and give it some extra code. If you add a new method to an abstract class, all you need to do is re-compile (and hope).

I'm sure there are other issues to take into account, e.g. interfaces possibly have a speed overhead from the extra level of indirection. I'll leave that to others...
The Sparx Team
[email protected]