Comments on: Anti-Patterns and Worst Practices – Utils Class

By: Dark Phoenix

Dark Phoenix — Fri, 07 Sep 2012 15:30:00 +0000

Well, I don’t really see a need for a Utils collection in something like Java/.NET, but I know in my PHP library I have a utilities file. It contains functions that perform generic actions on primitives that don’t really belong in any specific class (for example, merging two arrays, checking for string prefixes/suffixes, and so on). And even in that situation, when a lot of functions on one primitive start to pile up, it’s usually a clue to write a class abstraction over that primitive (for example, I have 15 or so string functions, so I’m working on refactoring them into a String abstraction class rather than leave them as loose functions).

By: Chris Missal

Chris Missal — Tue, 12 Jun 2012 13:52:00 +0000

Thanks for pointing that out, it’s fixed now. I also found some broken links that I could correct, cheers!

By: Any name which u like to call

Any name which u like to call — Tue, 12 Jun 2012 06:23:00 +0000

The code snippets are not line wrapped. It’s annoying.

By: steve

steve — Fri, 11 Mar 2011 21:07:32 +0000

I think Utilities classes are a great way to PREVENT code redundancy – they give the common developer a single place to look for utilities. Also they make code more readable.

I agree, that Log4J should be used instead of writing your own logger…. But in a typical application , there often exist clumsy , verbose API’s for doing simple tasks … i.e. low level API’s for executing queries. Its alot easier to read code that sais

List employees = db.getAllEmployees();
BeanUtilities.sortResults(employees, “birthday”);

then to write

Collections.sort(employees, new Comparable(Object e){
return java.util.Date.compare … (Employee)e.getBirthday()…….}; //you get the point !

Furthermore when internal APIs for such tasks are used, they encourage developers to actually USE the same mechanism and logic over.

Classes and object orientation are great, but its easy to get lost in a sea of objects…. Utilities classes that wrap objects and muddy APIs are extremely valuable.

By: AndyB

AndyB — Thu, 04 Jun 2009 04:10:13 +0000

Chris

After following the SRP and DRY principles a couple of times, what you explain above should become almost instinctive for a good developer.
What I mean by instinctive isn’t necessarily that you remove or avoid these Utility classes without thinking but rather when you see or think of them, you get that stench of bad / rotting code. Your design nose then gets more sensitive as you plough on to the next projects.
Anyways, good post!

@Ryan – a single Manager class or multiple XYZManager classes or both?

By: Ryan Svihla

Ryan Svihla — Thu, 04 Jun 2009 03:33:01 +0000

Can we have a special mention for “Manager” classes.

By: Chris Missal

Chris Missal — Tue, 02 Jun 2009 14:37:28 +0000

@Dustin
Ha, I like that… “MissalCode”

By: Dustin Thostenson

Dustin Thostenson — Tue, 02 Jun 2009 13:50:29 +0000

Yet another handy installment of MissalCode! Thanks Chris!

By: Daniel Fisher

Daniel Fisher — Tue, 02 Jun 2009 06:43:00 +0000

1) Since Extension Methods are in place ther mustn’t be Util-Classes

2) Take whats already in the platform: System.Diagnostics

Rgs,
Daniel

By: Chris Missal

Chris Missal — Mon, 01 Jun 2009 18:23:46 +0000

@Karthik
Foremost, you want to make sure that your classes only have one reason to change. If you’re looking to add something new, there’s likely a chance you’ll want to add a new class(es). Modifying existing functionality would probably allow you to keep the code in an existing class. As for naming it, something obvious is always good; I don’t mind long class names most of the time, intellisense helps speed things up so you don’t have to type the whole class name most of the time (there should be limits of course ;) A lot of this has to do with the domain you’re working in and there isn’t a set of rules you must follow, just keep an open mind and don’t be afraid to see and fix any mistakes.