> I'm sorry Brandon, but I have to agree with Scott on this point. The code in > the clients was unmodular and linear before, but the only thing that pulling > it > apart and leaving the code in a dozen different methods scattered throughout > the classes in no logical order (and with zero javadocs, and what does not > seem > like a planned interface) calling eachother left and right did was turn it > into > unmodular spaghetti.
The methods aren't calling each other left and right. They are discreet code blocks and the methods are layered. It is true that they could be ordered more clearly, but that's not really a big deal. I can do that tonight. > If we want the code to be useable as client library, then we need to carefully > consider what interface we want for the people accessing the client objects. > Ian's recommendation that we javadoc first, implement second, could not be > more > correct in this case. That wasn't an option in this case since I was restructuring existing code based on its already existing implicit structure (meaning I made methods out of the chunks of code that should logically be methods). I'm not calling this a finished product. It's an intermediate stage in the reworking. I still think it's much better than the previous monolithic client. At least now the code which is shared between InsertClient and RequestClient is taken out and put into Client instead of being repeated (with random variation) in both classes. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
