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.