Decorator Pattern

I always enjoy good blog posts on patterns.  This week the Los Techies blogger Sean Chambers covers the decorator pattern as part of the Pablo’s Topic of the Month (PTOM).

As always Sean does a good job explaining how the decorator pattern works with code snippets as well.

My favorite part is the explanation of why to use the decorator pattern instead of just a traditional inheritance model:

This would work, however it’s not very desirable. Eventually as you add more and more permutations, (Coffee w/ Espresso, Coffee w/ Espress and Whip cream, etc..) it would lead to a class explosion and you would have a new class for every new combination of ingredients someone could have for a cup of coffee. A better option would be if we could add or "decorate" the original cost and name with our added options. Enter the Decorator Pattern.

Check it out!

Cohesion & Coupling

Jeremy Miller’s MSDN article on Cohesion And Coupling.  Jeremy covers some of the OO ‘basics’ as part of his MSDN series ‘Patterns in Practice’ (see ‘The Open Closed Principle‘ article as well),  including

Decrease Coupling
Increase Cohesion
Eliminate Inappropriate Intimacy
The Law of Demeter
Tell, Don’t Ask
Say It Once and Only Once
Wrapping Up

As always, Jeremy does a good job explaining these software design fundamentals.

Document Map Margin

So I saw this in my VS studio ‘news’:

http://blogs.msdn.com/charlie/archive/2008/08/15/future-focus-document-map-margin.aspx

Now, I had to laugh, as I hadn’t read the actually post yet, but the synopsis is:

Developers frequently work with huge source files that are difficult to navigate. The proposed DMM feature is designed to make it easier for you to find and track important features in your code and to visualize the overall structure of your file.

So… my first thought was: why don’t they refactor it so you don’t have ‘huge source files’   

The real problem in my opinion is that rather than add a ‘document map’, how about we add better refactoring tools to help developers learn to get rid of these ‘code smells’ ?

ie. Resharper is good – but cost an arm and a leg as far as I’m concerned – meanwhile, the VS refactoring tools are kind of crappy – sure, it’s better than nothing, but they don’t even come close to what Resharper or Eclipse has.

Address the real issue 

Ajaxian Article: The seven rules of pragmatic progressive enhancement

http://ajaxian.com/archives/the-seven-rules-of-pragmatic-progressive-enhancement

I like his summary points:

1. Separate as much as possible
2. Build on things that work
3. Generate dependent markup
4. Test for everything before you apply it
5. Explore the environment
6. Load on demand
7. Modularize code

OCP Example

Agile Joe (Joe Ocampo) has a good post on the ‘Open Closed Principle’:

“The open closed principle is one of the oldest principles of Object Oriented Design. I won’t bore you with the history since you can find countless articles out on the net. But if you want a really comprehensive read please checkout Robert Martin’s excellent write up on the subject.

The open closed principle can be summoned up in the following statement.

open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”;[1] that is, such an entity can allow its behavior to be modified without altering its source code.

Sounds easy enough but many developers seem to miss the mark on actually implementing this simple extensible approach. I don’t think it is a matter of skill set as much as I feel that they have never been taught how to approach applying OCP to class design.”

Read the full post here.

Ayende on “A maintainable environment – anti corruption as a way of life”

Ayende has a post that exemplifies principles that I see as extremely important to a good development environment.

Some key points:

• • Infrastructure Ignorance – If I have to deal with my infrastructure explicitly, then I need to have developers dealing with it on a regular basis. That doesn’t mesh well with the idea of moving all the complexity to the infrastructure.
  • Fizz Buzz concepts – the code that a developer should write should be simple and easy to follow.
  • Follow good design principals – the code written should naturally lean toward single responsibility principal, separation of concerns, etc
  • Easy to figure out – It should be simpler than the alternative for any non trivial scenario. Ideally, you can explain how to solve most scenarios using this approach in half an hour or less (ignoring the infrastructure part, which may be very complex).
  • No training wheels – one of the things that drives me crazy is having two ways to do things. One for the average developer, the second for the architect. This usually comes out of putting training wheels on the first approach that make it hard to deal with in more advance scenarios. I see this as a sign of contempt for the rest of the members of the team. If you expect the rest of the team to work in a certain way, make damn sure that this is a way that this is a way that you can live with.

“The code that a developer should write should be simple and easy to follow”

There is so much about this that needs to be expounded upon. I really think the Single Responsibility Principle(SRP) is vital to this concept. I’ve seen some pretty ugly looking code all over the place where I’m at right now. Very large functions that are procedural in nature. I’d personally rather have many classes than classes stuffed with tons of code. Also, too much code in asp.net code behind pages is a major ‘no-no’. For myself, I’ve had to do much refactoring to get code back into business/presenter classes and out of the code behind. (This is one reason I like the Monorail/MS MVC approach). I could go on and on about this one.

“Easy to figure out”

Whew, amen here. Here is my code smell for this one: When you have no code in the business layer and all it is a pass through. Why do I say this ? Typically this means all the logic is in the UI or in the data layer. This is why I’m a big fan of a domain driven design with clean POCO business objects. Separation of Concerns is important here. I know it’s always debatable in the MS developer world, but when I see datasets I cringe. I think datasets tend to make developers think just in terms of the data layer. They are confusing to see the domain picture. So for me ‘Easy to figure out’ == well defined domain model.

I should add, I think creating a rules engine (IRules) and/or validation objects that can be kept away from the actual entity objects is important. This allows me to see the domain without clutter of all the rules (ie. different sets of business rules for a each client – the entity would hold a collection of ‘IRule’ objects associated to it’s particular instance)

The struggle is working in environments where principles aren’t openly discussed. I think ‘best practices’ should be complemented with developers all speaking a common language of good OO principles. On some teams I really enjoyed working with, stressing these principles made us a successful team, it was a very growing experience to me as a developer.

Great Site

Just today I ran across Rob Daigneau’s website – DesignPatternsFor.net . He has articles, blogs, sample code, presentations, etc… on this site.

Everything from good writeups on SOA, WCF, etc.. to how to build a Data Mapper, State Management, etc…

Just thought I’d pass this along. A wealth of good information.

Rob is the Director of Application Architecture at Monster.com

—

PS. My order from Amazon arrived today with two new books: the Pragmatic Programmer book on NUnit & C# 3.0 Design Patterns. So far it’s good. The Design Patterns book is interesting in that it’s not only reviewing the GOF design patterns, but also shedding light on the new C# 3.0 features and how they fit in. It’s a different approach that I’m enjoying so far.

PPS. New version of MS MVC and Silverlight 2.0 beta 1 were released at the MIX ’08 conference.  I like the updates to MS MVC.  Now you can deploy to a server with just the assemblies in the bin, nothing needed installed on the server.  There are other changes, learn more about them here.

oh , and I love this image…

That is me right now…

Learning from the best

My good friend Rob reminds me often that it’s about understanding the principles of software design, not just the latest greatest fads that really matures the developer. I’m in 100% agreement. Although I like to fiddle with all the fancy new stuff, it’s the learning of the basic OO principles that continue to really guide me.

Another wise developer, Billy McCafferty echo’s Rob’s mentoring advise in his post ‘Standing on the Shoulders of Giant’s’. The simple fact is that development is not only a science, but I feel an art as well. As a developer, I must admit I get a bit unsettled when looking at modifying API’s such as working with Biztalk, vs. working directly with code. At the same time you can, I believe, incorporate the same fundamentals with any of these technologies – Single Responsibility Principle, Loosely coupled and cohesive, etc…

What really sums it up I believe is that a principle that lives deep to my heart – ‘our challenges in life build our character’. We must see our challenges in this light.

Rob really illustrates this in his post ‘The Pain of Learning is Worth It‘ and ‘You Gotta Have Faith‘. I was glad to read these because it’s a true lesson in life, that as you climb each mountain, no matter how tough or daunting it might seem, there is a lesson learned that just adds to our life’s experiences and our character. Without some of these challenges, I doubt we’d really learn the powerful lessons at hand.

It’s exciting to have a profession where these lessons can be learned. I know personally that I’ve been fearful many times of the demons of ‘future fear’. But it’s amazing how I can look back and see a path carved out with it’s life’s lessons guiding the way.

At some point you have to really grab life by the horns and overcome the fears, realizing that those fears are but obstacles to realizing your own potential.

It’s good to have mentors along the way that can help point to the moon and remind me not to be focused on the finger pointing but the moon itself!

Pragmatic Unit Testing in C# with NUnit, 2nd Ed., 2nd Edition

I was out on the The Pragmatic Programmers website and saw this title on Unit testing that uses NUnit

New for the Second Edition:

• Updated for NUnit 2.4 (C#, .NET 2.0, Visual Studio 2005, and Mono)
• More NUnit assert methods
• New String and Collection assertion support
• Better support for multiple-platform development (Mono and .NET)
• Higher-level setup and teardown fixtures
• …and more!

I will probably grab this book after reading the chapter on ‘Using Mock Objects’. Using Mock Objects is something I’m getting into and it helps to have some guidance on their usage.