I borrowed the term “Brown Bag Lunch” from a former colleague of mine (Dirk Vangeison). The idea of the brown bag lunch is every month or so have a team member volunteer to host a 1 hour presentation over lunch (of course the attendees would bring their own lunch). Topics for a brown bag lunch might be design patterns, new technologies, SDLC, trouble shooting techniques, or new tools. It is a great way to transfer knowledge and really good way to develop presentation skills.

Friday, February 5, 2010

I am having some technical difficulties getting images posted to my new blog site so I’ll revise my statement. Very soon I will be blogging on an internally managed blog site at Intertech (http://www.intertech.com/blog/). I will not be moving existing content but I will continue to update the links on my design and code review check list until it is complete.

Composition is a method we use to combine simple objects into more complex objects. With composition we have an owner class that changes behavior by delegating the implementation of certain behaviors to smaller and simpler objects. When we destroy the owner object, all of these smaller objects the owner uses are also destroyed. If we were to use inheritance to achieve this same goal (changing behavior) we would use a subclass to change the behavior of the base class. As I mentioned in my last post, the base class and subclass are tightly coupled and this can tend to be a bit brittle.

Consider the very real case where we are writing an application that needs to work with both Oracle and SQL Server. We could use inheritance to define a base class and have one subclass for SQL Server and another for Oracle. Our application can figure out which object to instantiate at runtime and that will work pretty well. Here is what our class diagram might look like:

If we take a little different approach and use composition instead we might have a class diagram similar to the following.

The CompositionDatabaseWriter does not need to implement IDatabaseWriter but I did that because I think it makes the example easier to understand. The application will use the CompositionDatabaseWriter to do database work and CompositionDatabaseWriter will determine whether to use SqlServerDatabaseWriter or OracleDatabaseWriter at runtime perhaps by using a configuration file entry. When one of the CompositionDatabaseWriter methods is called, CompositionDatabaseWriter simply calls the corresponding method on the Sql Server or Oracle object.

Both designs allow us to interact with an oracle or Sql Server database which was our goal. Now here is where the flexibility of composition comes in; Suppose we now need to support a MySql database. If we use inheritance to solve this problem, at a minimum we must create a MySqlDatabaseWriter subclass, recompile, test, and deploy our data layer. If we use composition instead we can create a MySqlDatabaseWriter in a new assembly and all we have to do to use it is deploy this single assembly and change a config file. Very powerful, because we used composition we can change the behavior at runtime via configuration.

The fact of the mater is that our sample is so simple we didn’t even use composition at all so imagine the considerably more complex scenario where what we are doing is creating a persistence object that must transactionally work with the file system and a database. We define the persistence object and within the persistence object we delegate the responsibility of dealing with the file system to one class, and dealing with the database to another. The persistence object is composed of a FileSytemWriter and a DatabaseWriter. Our Persistence object has only one concern – coordinating database and file persistence. Our FileSystemWriter has only one concern – managing File System interactions, and finally our DatabaseWriter is only concerned about interacting with a database of one type. We have decomposed a fairly complex problem into a few smaller more managable problems, we came up with a nice robust design thanks to composition and we have managed to do it in such a way that there are no SRP violations either!

About Me

I'm Tim Star, an architect and senior .Net consultant with Intertech. I have almost 20 years of software development experience including writing 2K programs for embedded controls and working as a part of a team on a large enterprise app. The bulk of my work here at Intertech is in the area of .Net consulting. I have also done a fair amount of training on web and load testing using VSTS Test Edition, and some work configuring and deploying TFS. Prior to joining Intertech I worked for Intercim, a great little company right here in Eagan that sells a Manufacturing and Operations Management software package. At Intercim I wore a lot of hats. I started as a road warrior writing custom SPC applications, spent many years dividing my time between coding and management and eventually landed in a role as the application architect. Over the years I have had a terrific mentor (Jeff Star), fantastic former colleagues (the Intercim crew) and now some absolutely top notch folks to collaborate with right here at Intertech. The bulk of my blogs will be technical in nature but I will sprinkle in narratives as well. I am always looking for ways to build better software so comments are welcome.