Thursday, August 17, 2006

Training Day 2

Ok, well, it has taken me until half way through day 2 to realize that the title of the class is Design Patterns and Best Practices.

I thought we would be focusing more on design patterns, instead we are covering a lot of best practices. this is awesome. Unfortunately I think I have read about most of the best practices already. I also feel like with design patterns I have a very basic understanding, and I have not been able to understand a problem enough itself to be able to implement a design pattern on it.

I expected that I would possibly struggle through this class, but at the end at least have a better understanding. However, thus far, the teacher keeps coming over and asking if he's boring me because I am "quite advanced" and he doesn't want to be going too slow for me. No I'm not bored. I'm learning, I am even excited about what I'm learning. As with almost everything the examples are too simplified, but they do help.

We officially covered 3 design patterns today.
Decorator Pattern.
It's used to accomodate varying feature rich applications.
Why the decorator pattern?
You have many features that you want to be able to change during runtime, that are not fixed at compile time. This is also very useful for things that vary slightly over time.

Template Pattern (Hollywood)
The template captures a common algorithm that varies slightly over time. Such as Tax Returns. Known as the Hollywood because of the "don't call us, we'll call you" rule. The derived class does not call the base class, instead via polymorphism, the application is designed to the base class interface, but uses the derived classes updated features.

Adapter Pattern
The adapter pattern is used to allow an application expecting a certain interface to use an object that does not implement that interface, by implementing the expected interface and passing the calls on to the underlying object.
This is one that I have used more than once at work and it has been very useful. I was even lucky enough one time to realize that it was the adapter pattern.

There were also 2 unofficial design patterns that we learned.
Singleton Pattern
The Singleton pattern is very straightforward to use. But the reason is not always clear why we use it. We use the Singleton to allow shared data, uncouple objects, and share resources. We don't have to use it for all three reasons but those are the reasons to use a singleton.

Mock Object
The Mock Object used for Unit testing witn NUnit is a design pattern. This is probably one of the easiest patterns to recognize that we have to use, because we simple create a Mock class to use with testing. We did create a Mock object to test a simple class. I finally understand that the purpose of a mock object is to create a class that will expose previously hidden data from a class that will allow us to verify that the internal data is doing what it is supposed to.

We went over the rules of when to use Inheritence vs. when to use an aggregate pattern. The documentation has a great decision chart. I'll see if it's ok if I can post this decision chart in the future.

We used NUnit, not only for the simple Test attribute, but also to catch expected exceptions which I had not done, and to make a mock object.

We used some of the built-in refactoring tools of C# 2005. These are only built-in for C#. If you are a VB.Net developer and purchase a copy of VS2005 (VS2005 express does not count), then you can download a plugin called Refactor that will let you do the same funcitonality.

This was a great day, and at the end of the day I wished it could have gone longer again. Mostly though, I wished I had more time to reflect on the vast amount of new things I'm trying to learn.