axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: SerializationContext/DeserializationContext cleanup?
Date Thu, 09 May 2002 21:41:40 GMT
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.

-----Original Message-----
From: R J Scheuerle Jr []
Sent: Thursday, May 09, 2002 5:28 PM
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 <> 

05/09/2002 02:48 PM 
Please respond to axis-dev 

        To:        "''" <> 
        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. 
-----Original Message-----
From: R J Scheuerle Jr []
Sent: Thursday, May 09, 2002 3:40 PM
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 <> 

05/09/2002 01:51 PM 
Please respond to axis-dev 

       To:        "'Axis-Dev (E-mail)'" <> 
       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.


View raw message