SOLID Object-Oriented Design - Video presentation by Sandi Metz

From Gotham Ruby Conference 2009

Sandi Metz gives a very insightful walkthrough on the SOLID principles.

Util Classes Must Die

Using a lot of static methods in utils classes will make your application procedural rather than object oriented.

Util classes cause problems with / violates:

* OO in general: Code is not object oriented

* Testability: Static is hard to test

* Inheritance: You can not extend a helper class

* Polymorphism: Helper class can not derive from an interface / base class

* Cohesion: Several responsiblilties in a class breaks the single responsibility principle

* Encapsulation: Helper methods are procedures

Anti-Patterns and Worst Practices – Utils Class

Chris Missal blogs about Anti-Patterns and Worst-Practices, and mentions the utils class as an indicator of lazyness and lack of domain knowledge:

[...] know that there’s probably a better way. Since the problem I see with Utility classes is that they’re usually just a collection of a whole bunch of stuff that doesn’t really belong together, they probably exist for common reasons.

Source: http://www.lostechies.com/blogs/chrismissal/archive/2009/06/01/anti-patterns-and-worst-practices-utils-class.aspx

Are Helper Classes Evil?

Nick Malik has written two articles about the subject, and calls the helper classes an extraordinarily bad idea that should be avoided most of the time. Malik shows how helper classes breaks completely with object orientation (encapsulation, behavior) and several OO pronciples.

[-}the notion of functional decomposition is so easy that we drop to it when we come across an algorithm that doesn't seem to "fit" into our neat little object tree, and rather than understand the needs, analyze where we can get the best use of the technology, and place the method accordingly, we just toss it into a helper class. And that, my friends, is laziness.

What about making reusable code? Here's what Nick has to say about it:

The largest reusable code base that all your developers are already using is the .Net Framework. The vast majority of the framework uses instantiated classes, not static helper classes (there are exceptions, unfortunately). So, the need for reuse is NOT a good argument for helper classes.

http://blogs.msdn.com/nickmalik/archive/2005/09/06/461404.aspx

Helper Classes Are Evil

Eric Lee from Microsoft Game Stuidos takes a similar stand against the helpers in his blogpost Helper Classes Are Evil:

I very much dislike them in an OOP design because inevitably they becomes a dumping ground for all kinds of things that don’t relate to each other at all in the problem domain. It’s an attractive nuisance, to use a legal term. [-] a real adherence to OOP means that you’ll have lots and lots of small, single-purpose classes.

Next time you're tempted to put code into a helper class, take a step back and think for a second. Will this code violate OO and OO principles? Probably. What does the helper methods do? Can you design this so that the code is placed in a separate class with data and behavior? Don't be lazy. Try to understand the problem domain and come up with an object oriented solution rather than a lazy, procedural one.

So, must helper classes die? Let me paraphrase Nick:

I don't believe that software practices qualify in the moral sphere, so there is no such thing as evil code.

The Rise and Fall of a Software Company

I'm reading Robert C. Martin's "Clean Code", and this little anecdote really struck me. Many businesses go down this slope, since management and even developers do not understand the need for refactoring and redesign until it's too late.

I know of one company that, in the late 80s, wrote a killer app. It was very popular, and lots of professionals bought and used it. But then the release cycles began to stretch. Bugs were not repaired from one release to the next. Load times grew and crashes increased. I remember the day I shut the product down in frustration and never used it again. The company went out of business a short time after that.

Two decades later I met one of the early employees of that company and asked him what had happened. The answer confirmed my fears. They had rushed the product to market and had made a huge mess in the code. As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was the bad code that brought the company down.

Later in the book, Martin (aka "Uncle Bob") compares the development of software with the development of a city. You won't build a 6 lane superhighway in a little village. You don't have the resources, and noone even wants it there. When the town is growing, you will need to build a new infrastructure. You might need to tear down some houses to build a new highway that can handle the new reality.

It's a good metaphore. My lesson learned is: Know the danger of not redesigning. If you keep building on old infrastructure that should be replaced, your city might break down.

Microsoft Patterns & Practices: "Application Architecture Guide 2.0" (Book)

Download PDF version or read the book online:

http://www.codeplex.com/AppArchGuide

MEF - Managed Extensibility Framework

Video: http://www.dnrtv.com/default.aspx?showNum=130 (DNR TV)

Designing Data Tier Components and Passing Data Through Tiers

Building Distributed Applications - Designing Data Tier Components and Passing Data Through Tiers

http://msdn.microsoft.com/en-us/library/ms978496.aspx