axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: SerializationContext/DeserializationContext cleanup?
Date Fri, 10 May 2002 12:46:28 GMT

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
> 

Mime
View raw message