.NET Design Paterns for Agile Software Processes -- Kevin McNeish

Kevin is speaking on how to use design patterns to add extended flexibility and agileness to your software. One of the things that he is pushing is the use of Abstract classes and methods. I’m more of an interface guy, especially when you’re creating empty shells. Both will accomplish the same thing, but one, the interface way, is using the tool the way it should be (my opinion) used.

Kevin’s also showing the creation of the classes through the use of the Visual Studio class designer. I never used this tool to do the design of my classes. Usually when I use it I’m looking to do nothing more than create a pretty picture. The way the Kevin is using it proves that you can do so much more.

The point being made so far is that the code should be abstracte away so that you have the ability to change and adjust on the fly. He also points out that the creation of static classes will paint you into a corner. Instead you should implement a class that has an abstract property that exposes the business object that may be changed.

To explain the difference between interfaces and abstract classes, Kevin points out that, with interfaces, you can not add onto the interface after the fact without breaking the objects that implment that interface. It’s much more difficult to cause this problem when you are using abstract classes.

Tight coupling is good only if you’re into spooning and forking. In code it makes the application architecture far less extensible. The object that knows the most about the problem should be the object that solves the problem. Allow the objects to act on themselves by raising events. By doing this you can subscribe to the event with only the code that wants/needs to respond to the event. Use the Observer pattern to do this keeping in mind that you want to have a light touch when you are interacting with objects.

Using the Factory pattern lets you centralize the creation (newing up) of objects. Like so many things that we work on we want to centralize code changes. This is one item that is ripe for centralize that I had never thought of.

Bloody great presentation.