Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Message-ID: 
 <CB1FF0A474AEA84EA0206D5B05F6A4CB0102C4F2@S1001EXM02.macromedia.com>
From: Glen Daniels <gdaniels@macromedia.com>
To: "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
Subject: RE: SerializationContext/DeserializationContext cleanup?
Date: Fri, 10 May 2002 08:46:28 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


The SerializationContextImpl's public interface is almost exactly SerializationContext (constructors and one utility method being the only exceptions), and DeserializationContextImpl's interface (except for contstructors) is exactly DeserializationContext.  So this really isn't a case where there are a lot of implementation-specific public methods.  I still think this is a case of architectural overkill, but since the only other people commenting on this seem to think otherwise, I'll drop the argument.

--Glen

> -----Original Message-----
> From: Glyn Normington [mailto:glyn_normington@uk.ibm.com]
> Sent: Friday, May 10, 2002 4:27 AM
> To: axis-dev@xml.apache.org
> Subject: RE: SerializationContext/DeserializationContext cleanup?
> 
> 
> 
> I vote -1 to folding the SerializationContext and 
> DeserializationContext
> interfaces into their implementation classes since these 
> interfaces seem to
> be part of the interface to the encoding subsystem.
> 
> Building subsystem interfaces using java interfaces rather than java
> classes helps to reduce the coupling between subsystems. For 
> instance, a
> class which implements a subsystem interface may have a 
> method which is of
> no concern to other subsystems. If the subsystem spans more 
> than one java
> package, the method needs to be public. Then having a 
> separate interface
> means that the method need not be exposed to other 
> subsystems. (Granted, if
> the subsystem equates to a java package, you can use package scope to
> achieve the same ends, but package scope isn't obvious due to 
> the lack of a
> keyword to denote it and packages are not ideal for 
> constructing subsystems
> since they don't nest.)
> 
> Glyn
>