You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Peter Donald <do...@apache.org> on 2001/10/18 02:31:08 UTC
[PATCH][torque] Death to ObjectUtils
Hi,
I mucked about and noticed that only one method of ObjectUtils is actually
used and only in two places. This patch removes need for ObjectUtils by
pushing that single method (equals(o1,o2)) into the places where it is
actually used. The theory being that this simplifies readability of code and
removes a class that added complexity but wasn't really used.
After applying patch you should be able to do a
cvs rm ...ObjectUtils.java
--
Cheers,
Pete
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
Re: [PATCH][torque] Death to ObjectUtils
Posted by Peter Donald <do...@apache.org>.
On Mon, 22 Oct 2001 00:03, Jason van Zyl wrote:
> > 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.
>
> Cool, is it something that could be integrated into Alexandria? That would
> be a nifty tool to have at hand. Does it run as an Ant task? Something that
> could be integrated into a development cycle?
yep - I set it up in these projects to do metrics on a full build. I also
included unit tests that said things like if package foo is too coupled to
another package then fail etc. Recently there was a patch to ant1.5 tree that
allows you to generate reports similar to the junit report but for metrics. I
haven't actually used that though - so I don't know how good it is ;)
> That's what's happening, but it's been happening over a stretch of time. We
> have two versions of Torque kicking around with people using both so it's
> not moving that quickly. But the separated Torque is definitely meant to be
> a separated tool dealing specificially with persistence. The utility code
> has been slowly moving out. One code base at a time ;-)
;)
--
Cheers,
Pete
---------------------------------------------------------------
The difference between genius, and stupidity? Genius has limits
---------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH][torque] Death to ObjectUtils
Posted by Jason van Zyl <jv...@zenplex.com>.
On 10/21/01 8:52 AM, "Peter Donald" <do...@apache.org> wrote:
> 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.
The operative word there was simple, possibly a better word might have been
expedient. The code is undergoing some fundamental changes, and has been for
the last while, so I think he was just trying to limit the movement of code
for the time being. I think Daniel's suggestion of using the utility that
has been moved into the commons is probably the most sensible idea.
> 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.
That's definitely the notion that's been adhered to in trying to decouple
some of the larger portions of code from Turbine, and the notion being
adhered while redesigning Turbine 3.x.
> 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 ;)
These are more or less the ideas we've been using when decoupling bits of
the code over the last few months but even within the decoupled code bases
there is still a fair bit of work to do.
> 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 ;)
I think everyone would agree with that.
> 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?
I believe that method is used elsewhere which is why the utility was
moved to the commons.
>> // 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.
I'm not positive that it is only used in a single place. I agree that if 4
lines of utility code live in a class by itself and those 4 lines are
highly specialized and unlikely to be usable elsewhere than it's probably
fine to merge those lines into the client class. If the 4 lines of code may
possibly be used elsewhere than the separate class will encourage reuse,
whereas someone might be tempted to cut and paste the code from one class to
another. Like I did and than I forgot to clean it up. Once Daniel separated
it out into the commons I used that.
I'm sure there's little bits of code like this lying around. We still
haven't done the super-duper cleanup of the code bases. I'm currently trying
to move 2.x users forward to 3.x so that we can focus on the decoupled
torque and fulcrum code bases so we can look at all these issues.
> 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.
Cool, is it something that could be integrated into Alexandria? That would
be a nifty tool to have at hand. Does it run as an Ant task? Something that
could be integrated into a development cycle?
> 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.
That's what's happening, but it's been happening over a stretch of time. We
have two versions of Torque kicking around with people using both so it's
not moving that quickly. But the separated Torque is definitely meant to be
a separated tool dealing specificially with persistence. The utility code
has been slowly moving out. One code base at a time ;-)
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH][torque] Death to ObjectUtils
Posted by Peter Donald <do...@apache.org>.
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH][torque] Death to ObjectUtils
Posted by Daniel Rall <dl...@finemaltcoding.com>.
John McNally <jm...@collab.net> writes:
>> 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 added it to the Commons Util package when I created it in tthe
Commons Sandbox. I recommend adding the comment, changing the import
using the regex
's/(org\.apache)\.torque\.(util\.ObjectUtils)/$1.commons.$2/', and
dropping the copy from Torque (Commons Util is already an established
Torque dependency).
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH][torque] Death to ObjectUtils
Posted by John McNally <jm...@collab.net>.
Peter Donald wrote:
>
> Hi,
>
> I mucked about and noticed that only one method of ObjectUtils is actually
> used and only in two places. This patch removes need for ObjectUtils by
> pushing that single method (equals(o1,o2)) into the places where it is
> actually used. The theory being that this simplifies readability of code and
> removes a class that added complexity but wasn't really used.
A much simpler patch to improve readability and maintainability is to
add a comment where the code is being used.
// 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.
>
> 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.
-1
john mcnally
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH][torque] Death to ObjectUtils
Posted by jvz <jv...@zenplex.com>.
Peter Donald wrote:
> Hi,
>
> I mucked about and noticed that only one method of ObjectUtils is actually
> used and only in two places. This patch removes need for ObjectUtils by
> pushing that single method (equals(o1,o2)) into the places where it is
> actually used. The theory being that this simplifies readability of code and
> removes a class that added complexity but wasn't really used.
>
> After applying patch you should be able to do a
>
> cvs rm ...ObjectUtils.java
>
Thanks for the Torque patches. If Dan/John don't get to them I'll be back on
home turn Saturday
and I'll be working on Torque/Fulcrum/Turbine so I'll take a look a look at
them then.
jvz.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org