January 2009 Entries

Angela Binkowski covered Visual Studio 2010 focusing on the architecture tools at the most recent CAG meeting. This was a great evening with a lot of lively discussion. This would have been a great event for people who don’t think that Microsoft listens. As Angela was doing here presentation she was taking notes to bring back to the product team.

Some of the highlights that I found interesting included:

The Layer Diagram is a component or context diagram of sorts. The nice thing about this document, beyond the fact that we actually have one now, is that you can use it to validate that an application follows the general architecture.

Being able to generate diagrams that will show namespace dependencies and create sequence diagrams looks like it will be a real treasure when you are investigating applications that you have to maintain but are not familiar with.

I encourage you to follow this blog and the Chicago Architect Group website for updates on upcoming meetings. Come join our growing community.

I was listening to an episode of .NET Rocks in which Ted Neward spent some time discussing the direction that languages are going. This was predominantly a discussion of the DSL concepts, but the interview got me thinking about languages and how we design the internal structure of applications.

One of the main things that struck me was that something about objects has never felt quite natural. I have never found a decomposition technique that I was satisfied with. Looking at objects as nouns in your domain was an easy way to start. The problem was defining where operations lived. Some naturally belong within an object and others landed in a gray area. So you start creating objects that are data transfer objects which are operated on by objects that are method containers. When you do this you find that you are really just doing procedural development in an object environment.

Coincidentally Scott Hanselman had a show on SOLID with Uncle Bob (Robert C. Martin) around the same time as the .NET Rocks show. Below are the principles that make up SOLID.

Single Responsibility Principle

Open Closed Principle

Liskov Substitution Principle

Dependency Inversion Principle

Interface Segregation Principle

Note: Uncle Bob noted that he came up with the acronym before someone else suggested calling it SOLID.

These are the type of principles that I both admire and they drive me nuts. On one hand you have a “duh” moment when you are told to limit the number of reasons that an object should change to one. On the other hand, the lazy developer inside you says “that is going to take a lot of typing” as you create ever larger numbers of objects.

Ted indicated that we thought that objects were the way god thinks about the world and this was the end-all-be-all. In reality we find that some parts of software should be simpler or even abstracted further. This is why we are coming up with more scripting languages as well as DSLs with code generation. If a concept calls for a lot of detail but is one logical unit that can be reused then abstract it to a higher level. Don’t right it repeatedly at its lowest level.

One of the best questions brought up was “what do you want from a language”? This is a great question which of course brings up more questions. Where do you draw the line between language and design. Ted commented that languages are designed to reduce complexities so that we can attack greater complexities. This is another one of those “duh” moments, but if we don’t keep this in mind we will often use the wrong tool for the job at hand.

The key is to use tools and techniques where they make sense. Dogmatic use of a single technology or design approach is an invitation to disaster. Fill your tool box with hammers, chisels, screw drivers and anything else you can acquire so that you aren’t using a butter knife to carve a wooden figure. Learn as many languages and software packages as you can find time to. Don’t worry like most people do about forgetting what you leaned. It will come back to you when you go to use it again.

In the end the best tool you can ever have is knowledge and experience. Evaluate what you have learned after each project and leverage that for the next. Never stop looking for a better mouse trap, but if a simple spring trap will work use it.

Tim is a Solutions Architect for PSC Group, LLC. He has been an IT consultant since 1999 specializing in Microsoft technologies. Along with running the Chicago Information Technology Architects Group and speaking on Microsoft and architecture topics he was also contributing author on "The Definitive Guide to the Microsoft Enterprise Library".