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:[EMAIL PROTECTED]] > Sent: Friday, May 10, 2002 4:27 AM > To: [EMAIL PROTECTED] > 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 >
