Re: Interface freeloading on a superclass - is it good practice?

> >So all in all, unless my prediction of trouble ahead is flawed, I think
you
> >need to go back to the drawing board on this one.,..
> >
> I fail to see your point.
> If Sun suddently changed the signature or function of, say,
java.awt.Component,

Who's talking about changing any method signatures? That's not what I said,
I wrote "reimplementing [methods], possibly with their functionality subtly
changed".. in other words I'm talking about the precise semantics of a
method being subtly changed. The method signature isn't touched at all.

The problem with your scheme is that

a) you pick arbitrary methods from abstract/concrete classes which are not
the subject of any interface contracts written by the same authors of the
classes

b) you define an interface which contains those same methods (as signatures
only, obviously), and by doing so you "freeze" a particular *semantic
contract* for these methods

c) you now subclass a third-party class (Sun's), and impose on this class
your interface's contract.

>From now on, any future changes to the *precise semantics* of the methods
you picked, as altered or enhanced or rewritten by Sun, may very likely
break your scheme.

Why? Because Sun don't know or care about your interface's rigid semantic
contract, but you do... and suddenly the methods you tagged as "belonging"
to your interface don't match the semantics you imposed on them. The Sun
changes lead to a branching in semantics for these methods: one branch for
Sun's semantics, and one branch for your interface's semantics. Now guess
who's going to loose the battle of this splitting evolution? You, not Sun,
since Sun aren't even aware some clever guy decided to try to impose a
semantic straightjacket on a subset of Component methods....

> So i am resting quite assured that it won't happen.

Do you understand the scenario now?


.

Relevant Pages

  • Re: Interface freeloading on a superclass - is it good practice?
    ... > Who's talking about changing any method signatures? ... > the subject of any interface contracts written by the same authors of the ... any future changes to the *precise semantics* of the methods ... Because Sun don't know or care about your interface's rigid semantic ...
    (comp.lang.java.programmer)
  • Re: Some confusion regarding braces
    ... On Sun, 4 Jun 2006, Darren New wrote: ... And LISP. ... Heck, LISP's semantics can be pretty much specified in under a ...
    (comp.lang.tcl)
  • Re: OO versus RDB
    ... The semantics of RM is the semantics of the real world objects? ... What happens if some facts are wrong? ... emphasis on "design by contract". ... containers of strings, constrained strings, strings of various types of ...
    (comp.object)
  • Re: EULA Issues
    ... Any contract is hard to defend in court -- by the time you're their, ... understanding the semantics of the contract. ...
    (borland.public.delphi.non-technical)
  • Re: Collection vs well defined transfer objects
    ... > help with the semantics of the contract. ... > Type systems and naming conventions are utterly inadequate for defining ... NearLocation (and apply the constraint) whenever A::doIt needed it. ...
    (comp.object)