[jdom-interest] Another plea for Interfaces and other musings

[Paul Philion]

Max -

I agree with you on the "interface" issue, and there have been a number of
situations that I would have preferred interfaces in JDOM.

In summary, there are many instances where I have a different object or
object graph that I want to represent as XML. If I could "implement" Element
interfaces for the objects, they could simply behave as Elements and I could
manipulate them as I might any other. As it is now, if I need to go to or
from my "real" object structure, I literally have to copy attribute values
back and forth. In general, it is much more natural for me to think in terms
of interfaces.

I don't think the "performance" issue is reasonable. Yes, it takes longer to
dispatch a call thru an interface than it does directly to an object. But I
would rather have a clean, flexible implementation to match my design then
save that extra tiny bit of time. There are much better places to optimize,
and using interfaces allows a better opportunity to optimize in many cases.

That's my 2 cents, and I know that Jason (respectfully) disagrees with me.

- Paul Philion

> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Maximilian A. Ott
> Sent: Thursday, March 15, 2001 2:33 PM
> To: Jdom-Interest Mailing List
> Subject: [jdom-interest] Another plea for Interfaces and other musings
>
>
>
> I have been using JDOM since last summer in our product as well as in a
> graduate class I'm teaching to an audience with little XML experience. For
> whatever reason I completely missed this newsgroup.
>
> Over time I have added stuff (such as a builder factory) to support the
> things we are doing. Recently I been evaluating our requirements
> and I admit
> having some problems positioning JDOM.
>
> My main interest is not in XML (one can view it is as just a glorified
> encoding scheme), but in manipulating tree structures. So in some of our
> implementations, elements are not just passive representations, but active
> objects where the name/NS identifies their semantics (that's why
> I needed a
> factory). I also have a more relaxed view of the parent/child relationship
> in that I'm not sure that the single parent restriction is a
> sacrosanct one.
> But I know too little about the XML standards to judge if that is a fixed
> requirement. I wonder if there was already a discussion on that I missed
> when looking through the archives.
>
> Is it essential to be able to walk up the tree? Or is it enough to just be
> able to walk down? If the same sub-tree can be attached to
> multiple parents
> it makes many things much easier (at least for me). Obviously,
> there is the
> possibility of loops (but we are all software professionals and don't do
> that :)
>
> One thing which struck me as odd, was the omission of interfaces. I read
> with great interest the discussion last December and better put on my
> asbestos suit here as the exchange was quite heated.
>
> Jason (I think) was very vocal about no one ever having presented a good
> enough user case. That got me thinking. Why am I always starting with an
> interface? Just old habit? Not really. I have been building distributed
> computing middleware for the last 15 years and I can't frankly
> think of any
> other way to provide "location transparent" object references in
> a strongly
> typed language without interfaces. If I want to return a reference to an
> element in a remote call I need an interface to allow the remote side to
> build the stub.
>
> Despite the web, the grid, what-have-you, I'm most likely representing a
> very small group wanting distributed computing abstractions.
>
> Better let's re-visit the arguments against:
>
> * Needs factories and they are "in-your-face":
> ----------------------------------------------
>
> I still don't understand the "in-your-face" argument. In fact, I
> have found
> factories one of the cleanest constructs to hide heterogeneity
> from the user
> of a framework. But I agree, "new" is being discussed on page 5 of any
> introductory book on Java, "factories" most likely don't even make the cut
> until the advanced version.
>
> Would we really need factories with interfaces? There seem to be no way
> around them for creating the initial Document (bootstrapping). But after
> that?
>
> Element addRootElement(String name, Namespace ns)
>
> And for the Element themselves:
>
> Element addElement(String name, Namespace ns)
> ^^^^ Note, this returns the newly added element and not the element
> modified.
>
> Obviously, there is a desire to limit the number of methods of each class,
> but that is always a balancing act.
>
> I know there would be other issues to consider. For instance, all
> the addXXX
> calls return the modified object, allowing chaining of calls. My above
> suggestion changes the semantics of that return which could be confusing.
> But I'm sure that if one takes the time to through all that carefully, a
> common semantics can be established.
>
> * Performance:
> --------------
>
> That argument was only mentioned in passing, but might indeed be the real
> reason for trying to avoid interfaces at all cost.
>
> I admit that I have so far never worried about performance of my Java
> implementations. They were all "proof-of-concept", and clean design and
> extensibility was the major goal. That will change soon as I'm in the
> process of populating a rack with server to build a testbed and have a
> student standing by to try to bring everything to its knees and
> create a lot
> of graphs in the process.
>
> I'm wondering if anyone could comment on the overhead of
> interfaces in Java.
> I have a very good understanding of the trade-offs for C++, but not for
> Java.
>
> * Wrong tool:
> -------------
>
> As mentioned at the beginning, I'm starting to wonder if JDOM is even the
> right library for doing anything beyond reading XML files and creating a
> representation of some internal data set to be written out as XML. Similar
> to the serialization layer in ORBs (CORBA, RMI, COM, may add SOAP
> as well).
> Maybe the "users" of these frameworks soon don't see that anymore, but use
> tools such as IDL, or better here, CATO and the likes to map the
> "persistence" representation of XML files/DB, or wire
> representation (SOAP)
> to "pure" objects (I know CORBA and the like  and the like require you to
> subclass from their specific "Object" classes, but that is not
> necessary and
> just pure laziness on the side of the ORB designers - ok, the standards
> writers, too).
>
>
> If you are still reading, thanks!
>
> Comments would be greatly appreciated.
>
> Thanks again,
>
> -max
>
> ---
> Maximilian A. Ott
> semandex.net                       tel:+1.609.720.4913
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yourad
dr at yourhost.com