[jdom-interest] Re: Interfaces?

[Joseph Bowbeer]

To recap, Jason says interfaces are "been there tried that" and Brett
says there are other ways to achieve the same results.

If someone wants to work out the details of interfaces (again), I'd be
interested in seeing how much pain they introduce.  Also, I'm interested
in knowing what other ways Brett has in mind.

In the near term, though, I was wondering whether the "Visitor Pattern"
might be used to support extensions, as follows.

Given a Visitable interface defined by JDOM:

    interface Visitable {
        void accept(Visitor visitor);
    }

Each concrete object in a document would implement Visitable, for
example:

    class Element implements Visitable {
        // ...
        public void accept(Visitor visitor) {
            visitor.visitElement(this);
        }
    }

JDOM would also define an abstract base class for visitors:

    abstract class Visitor {
        public void visitDocument(Document document);
        public void visitElement(Element element);
        public void visitAttribute(Attribute attribute);
        // ...
    }

(Visitor can be thought of as "subject-oriented" rather than
object-oriented, I believe.)

Would it be beneficial to add Visitor/Visitable to JDOM?


----- Original Message -----
Date: Thu, 21 Sep 2000 18:21:31 -0700
From: Alex Chaffee <guru at edamame.stinky.com>
Cc: jdom-interest at jdom.org
Subject: Re: Interfaces? (was: W3 DOM support)
Reply-To: alex at jguru.com

Scanning old threads, specifically this one on whether Element et al
should be interfaces:

> And I'm not a big fan of subclassing.  I'd rather delegate.  To my
> mind, subclassing is fragile, often requiring intimate knowledge of
> the source code and leaving oneself vulnerable to future revisions
> of the base classes.
>

Inheritance is syntactic sugar (like all OOP actually).  Delegation is
strictly more powerful than inheritance, since all inheritance buys
you is that you don't have to write

 int foo(int bar) {
   return parent.foo(bar);
 }

for all methods you neglect to implement yourself.  Plus, inheritance
has baggage like the abovementioned, and like forcing you to use a
single (inherited) implementation instead of allowing swapping
different implementations in and out.

Note that inheritance is not the same thing as polymorphism, which
rocks.  Inheritance = polymorphism + code sharing

--
Alex Chaffee                       mailto:alex at jguru.com