Hi Oleg, > at the > moment we should concentrate on getting the core modules to ALPHA > release level first.
I fully agree. >>From the design point of view, I was surprised to see two different >>entities for compression and decompression. We had a long discussion >>about distinguishing incoming from outgoing entities and opted for a >>symmetrical interface in the end. Now, the distinction is creeping >>back in on the implementation level? >> > > > I know we argued a lot about this one. Conceptually the idea of having > separate interfaces for incoming and outgoing entities was nice. > However, it practical terms such a design decision would imply having to > cast every HttpEntity instance to either interface in order to be able > to consume its content, which was way too much of a sacrifice for the > design purism's sake. Actually, the casting became necessary because you wanted to use classes and interfaces on the server as well as on the client side. So you had to define attributes and return values with the common interface, because the associations request/outgoing and response/incoming apply only on the client side and are reversed on the server side. That design decision improved code re-usability and decreased the total lines of code we need, so I fully support it. > So, we ended up having one interface to represent > all types of entities solely for practical reasons. Therefore I do not > see a big problem is having one way entity wrapper classes (representing > pure incoming or outgoing entities) on the implementation level. I've spent a few minutes thinking about merging the compressing and decompressing entities into one class, but the result makes my brain twist whenever I try to imagine a stack of entities. That's a sure sign of a bad idea. Maybe I should publish an article about a new design pattern, "Escher" :-) http://www.mcescher.com/Gallery/back-bmp/LW389.jpg I am still a little itchy about the fact that such a clear distinction on the implementation level is not reflected in the interface hierarchy. But introducing tag interfaces without additional methods is pointless. JavaDocs will suffice. > So true. I know I suck at writing documentation > You fully compensate with the code :-) cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
