Comments on: Static Utility Methods http://andypalmer.com/2008/05/static-utility-methods/ Views on software, technology, consulting and business process Sun, 31 Jan 2010 16:31:55 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Andy http://andypalmer.com/2008/05/static-utility-methods/comment-page-1/#comment-4 Andy Thu, 22 May 2008 16:38:00 +0000 http://www.andypalmer.com/blog/?p=7#comment-4 It's true with StringUtils.reverse that I would be unlikely to want to change the implementation, but I would much rather write:<br/>"abc1234".reverse();<br/>than:<br/>StringUtils.reverse("abc1234");<br/><br/>I think if I bumped into one of the instances I mentioned where I wanted to be able to change out the configuration at runtime, then I would use an instance wrapper around a static method...<br/><br/>My opinions are no way set in stone, it's just that static methods make me feel icky and I'm not 100% sure why :-) It’s true with StringUtils.reverse that I would be unlikely to want to change the implementation, but I would much rather write:
“abc1234″.reverse();
than:
StringUtils.reverse(“abc1234″);

I think if I bumped into one of the instances I mentioned where I wanted to be able to change out the configuration at runtime, then I would use an instance wrapper around a static method…

My opinions are no way set in stone, it’s just that static methods make me feel icky and I’m not 100% sure why :-)

]]> By: Mc http://andypalmer.com/2008/05/static-utility-methods/comment-page-1/#comment-3 Mc Wed, 21 May 2008 12:05:00 +0000 http://www.andypalmer.com/blog/?p=7#comment-3 You'd have to involve at least 3 classes and some DI library refs to accomplish your two strategies scenario. Even then you're still coupled to one of those 3 types (interface or abstract class supertype). This complexity may be appropriate at some times, but the setup/overhead/code is overkill for a great number of common cases. Think of Math.cos or StringUtils.reverse - very unlikely that'd you'd want to change those, much less do the plumbing for keeping instances of those utility class available in some global context.<br/><br/>Your post did leads me to wonder: what if static methods could be "extended" how might that work. I certainly haven't thought through that extensively. I'm sure the java language people have, and there must be great reasons why its not possible.<br/><br/>Maybe look at it this way: using "composition," you can make whatever instantiable utility classes to wrap any existing other classes/methods you find are otherwise unsatisfactory. You’d have to involve at least 3 classes and some DI library refs to accomplish your two strategies scenario. Even then you’re still coupled to one of those 3 types (interface or abstract class supertype). This complexity may be appropriate at some times, but the setup/overhead/code is overkill for a great number of common cases. Think of Math.cos or StringUtils.reverse – very unlikely that’d you’d want to change those, much less do the plumbing for keeping instances of those utility class available in some global context.

Your post did leads me to wonder: what if static methods could be “extended” how might that work. I certainly haven’t thought through that extensively. I’m sure the java language people have, and there must be great reasons why its not possible.

Maybe look at it this way: using “composition,” you can make whatever instantiable utility classes to wrap any existing other classes/methods you find are otherwise unsatisfactory.

]]>