On Fri, 19 Oct 2001 01:12, John McNally wrote: > A much simpler patch to improve readability and maintainability is to > add a comment where the code is being used.
Thats not the hard or complex bit. In SE the complexity of a system is determined by a number of factors. One of those factors being "surface area". The more public classes and the more public (and to a lesser degree protected in java) methods in a system the more "surface area" a product has and the harder the product is to use and evolve. Smaller tighter interfaces mean that a product can be more stable and reliable over its lifetime - even if the implmementation of interfaces changes radically. (Sometimes this is also called afferent coupling*). Another factor in system complexity is the degree of coupling to rest of system (I think this is called efferent coupling*). So if class X depends on class Y then you automatically increase complexity of system to a degree (often this is ofset due to benefits of not duplicating things). The complexity of class increases even more when this dependency is via a public interface (which it needs to be if the classes are not in same package). * I think I may have mixed up afferent/efferent coupling terms but you get the idea ;) The reason to decrease complexity is because more people will use the system and thus you will hopefully see more people help developing the system ;) Now the code in question has several methods and adds a fair chunk of code. And this is to reuse about 4 lines of code. These 4 lines of code are simple that are highly unlikely to have a bug in them. So is the added complexity really worth the addition of this class? > // compares objects using Object.equals() method while allowing for null > values > ObjectUtils.equals(o1, o2); > > duplicating the code in this method all over the place does not strike > me as a better solution. It is 4-5 lines duplication and removes a whole class. I see that as a very acceptable tradeoff. Recently I have been using JDepend to generate metrics about some of my projects. I would recomend that you use it to explore the characteristerics of this project and others because it is very useful tool to decrease complexity and improve quality of a system. It takes a bit to interpret the results sometimes but a useful tool none the less. There are also more fully functional comercial tools available. They are a little easier to use but cost lots of $$ last time I checked. > > After applying patch you should be able to do a > > > > cvs rm ...ObjectUtils.java > > I use this class. I am sure others do also. This class used to belong > to the utility code found in Turbine-2 and was moved here as torque was > using the equals method. Not every class in Turbine had to be used by > the turbine package. It can be there to be used by application code. > It seems like this code belongs more in a package within the commons > repo, but until it is moved to a more appropriate location within > jakarta, I want it left where it is. And I do not see any reason torque > should not use it. I was under the impression that torque was designed to be independent of the rest turbine (at least the turbine-3 version). Wouldn't it follow that it should be focused on doing one thing and thing only (ie persistence/buisness object layer) rather than also serving as repository for other utility code. -- Cheers, Pete -------------------------------- My opinions may have changed, but not the fact that I am right -------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
