YAGNI
= You Ain't Gonna Need It :)
You
can design a perfectly usable class which has public methods defining a
clean public interface without actually splitting out a full-fledged
separate Interface class. I'm -1 on using public fields, +1 on good
interface (as opposed to Interface) design, but -1 on unnecessary Interface
classes. Explicit interfaces are good when you expect multiple
implementations, and I don't believe this is a case like that, at least not
yet.
As for
why it's an actively good idea to get rid of them, I'll give two
reasons. The first is simplicity - it cleans up the code, shortens the
list of classes a newbie needs to understand, and makes it clearer what's
going on. The second is related, but more procedural - any developer using
these classes might want to trace the execution of a particular path through the
code. If everything uses the interfaces, then this stout fellow must
remember to look at the implementation class to see what's actually happening,
not the interface. There are a lot of tools out there that help you trace
through code, and let me tell you they're really handy. One of the
features of such tools is the ability to click on a method and zap you
instantaneously to the source code for that method. If everything uses the
interface, you go there instead of to the implementation, which is rather
frustrating.
This
would be fine with me if there were actually a good reason to split out these
interfaces, but I don't think there is in this case, so Occam's Razor seems to
say get rid of them. The JAX-RPC interfaces are the "real" interfaces,
which are that way so that lots of different JAX-RPC implementations can
implement them in a semi-portable way. Axis' implementations of these
interfaces do not, IMHO, need another layer of interface.
--Glen
-----Original Message-----
From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 09, 2002 5:28 PM
To: [EMAIL PROTECTED]
Subject: RE: SerializationContext/DeserializationContext cleanup?
The interfaces define the methods for using the SerializationContext and DeserializationContext. I don't see how this hinders development. In fact it helps development, since it forces committers to use the interface instead of communicating via visible fields.
I don't know what YAGNI means.
BTW, you never did give an explanation to why you wanted to get rid of them (except your own personal convenience (?)). Please back up your arguments or drop the discussion.
Again +1 to KEEPING interfaces.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Glen Daniels <[EMAIL PROTECTED]> 05/09/2002 02:48 PM
Please respond to axis-dev
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: SerializationContext/DeserializationContext cleanup?
I guess what I'm saying is that I don't think this is a place where there is going to be any call for pluggability. YAGNI.
--Glen
-----Original Message-----
From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 09, 2002 3:40 PM
To: [EMAIL PROTECTED]
Subject: Re: SerializationContext/DeserializationContext cleanup?
Generally, separating interfaces from implementation is a good thing.
For one, it gives us the opportunity to make this a pluggable piece in the future.
Also it establishes better boundaries between the components. Before I made these changes,
there was a lot of interactions between components using public or package visible fields.
I feel that the Context classes are a lot better off (and remain better organized) now that we have
interfaces. I would vote -1 to removing the interfaces.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Glen Daniels <[EMAIL PROTECTED]> 05/09/2002 01:51 PM
Please respond to axis-dev
To: "'Axis-Dev (E-mail)'" <[EMAIL PROTECTED]>
cc:
Subject: SerializationContext/DeserializationContext cleanup?
Does anyone (Rich?) have any real reasons why we have SerializationContext and SerializationContextImpl? I know the JAX-RPC SerializationContext is an interface we have to implement, but it seems to me we could just as easily (and much more conveniently) have axis.encoding.SerializationContext be a class instead of introducing yet another interface.
Same holds for DeserializationContext/DeserializationContextImpl.
Do you think these are useful + important points of extensibility? Are there really going to be other implementations?
If we could coalesce these guys, that would make my life a happier place.
--Glen
