Posts tagged Object-Oriented

Out of all the SOLID principles the one I feel the strongest about is Dependency Injection (DI).  The motivational poster Derick Bailey created sums it up the best.  Why are we hard-coding our systems together, making them harder to test, and harder to change?

Containers evolved to support DI at runtime so we could apply inversion of control.  Containers also give us some other things we can leverage besides just keeping track of all those dependencies.  We have to be careful not to go container crazy though!

Containers can manage object lifetimes.  Ever had to write a singleton?  With the availability of containers you almost don’t have to anymore.  Before you write your next singleton, think about letting a container manage that lifetime for you.

Use containers to enforce interface/abstract dependencies. Refer to the motivational poster referenced above.  Do you really want to solder the light to the socket?

Make sure you initialize and maintain the container at the right level.  Ideally your application should have one container to serve all.  In WCF you want this to be at the Service Host level.  In ASP.NET it will be something initialized in global.asax.

Encapsulate your container initialization in a class.  I refer to these classes as “Providers”, ex StructureMapProvider or ContainerProvider (Manager might also work too).  This class should be responsible for initializing the container and maintaining the reference to it.  When you need to change your dependencies there’s one place to make that change.

Use containers to handle abstractions built around third-party dependencies or types you don’t own.  Be careful not to follow this anti-pattern pointed out by Jeffrey Palermo.

Favor code based configuration over .config files. Say what?  Configuration files are great for a lot of things.  By setting up a container in one you may think, “Great, now I can just change the .config to add new types, etc”.  Realistically you are probably never going to do that.  Why do I say this? Because I used to believe that I would use .config that way. And it never happened.

Currently my favorite container is StructureMap.  Your mileage may very and fortunately, there are a lot of choices out there.

Design Patterns have been around for some time now but many of us are still learning how and when to leverage these powerful concepts for engineering software.  Design Patterns have also been the source of backlash for those who have suffered under design pattern crazed architects.  As with any useful tool or concept the balance lies somewhere in the middle.

Patterns exist even when you don’t see them.  If I had to choose a way to describe my early programming career (classic ASP & MS Access/MySql) it would be “DRY” (don’t repeat yourself).  I spent a lot of time doing things to avoid duplicate work.  In ASP this meant lots of include files and shared routines.  This led to some common patterns that I used to tackle certain problems; by no means were these actual design patterns, it was just a way I found to best solve the problems I encountered.  Looking back on that early experience I see how the design patterns could have helped.

When framing the problem if you see a pattern try to leverage it to solve the problem.  Before the holidays the project architect (We’ll call him “Brad”) and I were trying to tackle a problem.  As he was looking at what we were doing he suggested the strategy pattern.  We weren’t sure it was a good fit but it gave us something to look at to help us with the problem.

One of the barriers to understanding patterns is a lack of real-world examples.  If you study the strategy pattern I referred to above you’ll see most of the examples discuss simple calculations, A+B type of stuff.  That is helpful, but what if I have 4 factors that are needed to calculate the price and there is other data we must include with the price, like if there was a discount, etc?  Does that mean I can’t use the strategy pattern?

Patterns require you to generalize and forget about your specific domain.  This is probably the hardest part.  A lot of people think that their situation is totally unique; for the domain it may be, but in reality a lot of people have the same problems.  This is where patterns really help.

One of my goals for 2010 will be to continue studying and applying patterns where they fit.  Some great resources I’m using are:

• Head First Design Patterns
• Design Patterns for Dummies
• Uncle Bob’s Principles of OOD (SOLID)
• Colleagues, friends, community leaders, and people smarter than me