Why is it important for a class to have a single reason to change and what are its benefits? One of the easiest ways to enhance the maintainability of a code base is to have it loosely coupled. In loosely coupled code, a change to one feature does not affect any other functionality. It is the opposite of spaghetti code where everything happens in one big method and changing how one functionality works very likely affects all the other functionality. And to get this loosely coupled code, each feature should be broken up into individual classes. If each class implements only one feature, then it only has one reason to change and when you change that feature you don’t have to worry about it breaking anything else in the code base.

A good example of a violation of the Single Responsibility Principle is having data validation and storage in the same class. Take a look at the code below as an example.

public virtual void Save(User user)
{
  if (string.IsNullOrEmpty(user.Name))
    throw new ValidationException("User name cannot be blank");

  using (var conn = new SqlConnection("connection string"))
  using (var command = conn.CreateCommand())
  {
    command.CommandText = "INSERT INTO USERS (Name) VALUES (:name)";
    command.Parameters.Add(new SqlParameter(":name", user.Name));
    command.ExecuteNonQuery();
  }
}

This code violates the Single Responsibility Principle because it performs two tasks: validating the object and persisting the object. These two responsibilities are orthogonal to each other and should be separated out to two classes since neither one affects the other.

Now that I have explained this design pattern, I want to give my opinion on its usage. I believe this principle is good to follow when designing applications but I don’t think it should followed to a T. I say this because I see some people take it too far. For instance, take for example the interface below.

public interface Modem
{
  public void Dial(string phoneNumber);
  public void Hangup();
  public void Send(string message);
  public string Receive();
}

Some would say the methods on this interface need separated out into 2 interfaces, one that takes care of the connection (Dial and Hangup) and another that takes care of the communication (Send and Receive). Personally I disagree. Yes, I can see how some could consider there being 2 responsibilities in this class, but then what is to keep the interface from being broken up into 4 interfaces, one for each method, because I could also see how Dial is a distinct responsibility from Hangup and Send is a different responsibility than Receive.

As far as implementing the Single Responsibility Principle, I personally advocate that there needs to be a sliding scale on how fine tuned the responsibilities are split out.

Before I expound on my position further, I need to introduce a term called responsibility group. A responsibility group is a set of responsibilities that correlate to each other in one way or another. The size of a responsibility group can be anywhere from large to small. The smaller the responsibility group, the more closely each responsibility correlates to each other, and the larger the group, the more loosely the responsibilities correlate to each other.

The smaller the application, the larger the responsibility group should be, and the larger the application, the smaller the responsibility group should be. The graph below shows a visual representation of what I’m talking about.

I advocate this view as a result of my own experience. I volunteer my time at a non-profit organization where I have developed quite a few applications to help automate some of their administrative tasks. Many of these applications are quite small with less than 100 lines of written code. In these applications do I separate out the validation logic from the persistent logic? No, it’s not worth it. If I did I would very likely have more classes than I did lines of code. However, in my open source project (Linq to Excel) I have much smaller responsibility groups since it’s a larger project with many features.

One of the arguments for using this principle is making the code easier to maintain and add enhancements. But with small applications that serve a single specific purpose, it’s quite unlikely that they will change. And even if they do change and enhancements are added, the Single Responsibility Principle with smaller responsibility groups can be implemented by refactoring the code when the enhancements are added.

These are my thoughts and 2 cents worth on the Single Responsibility Principle. I know I do not follow the main stream of thought for this principle so I would love to receive feedback on my ideas on this principle. What is your experience with using this principle?

I would like to cover the business problem I had and how I used jQuery to solve it. One of the internal web sites at my company has a user rights management page where an administrator can control the individual rights on the site for each user. This page has a drop down list of all the employees which is used to give rights to a specific employee. The problem was the drop down list was not alphabetized and it contained over 1,400 employee names to choose from! It felt like finding a needle in a haystack every time a new employee was given rights.

The root cause of the issue was the use of a hacked together database view that returned the list of employees ordered by their full name. Database views are not supposed to have order by commands, but this one did and the website was expecting the view to provide the ordering. However, the view was not returning the employees as properly ordered. After some research it was found that the database optimizer figured that bypassing the view and using the data directly from the table was more efficient than going through the view, which meant that any code using the view would receive an unordered list of employees.

Once that was figured out I was able to add an order by to the sql command and the drop down list was now ordered correctly.

However, there is an acronym we often use at work as our motto: MISL (pronounced missile)

Make
It
Suck
Less

And only alphabetizing the list did not Make It Suck Less enough for me. It was still a pain the neck to scroll through the 1400 employee names in the drop down list.

My solution was to use jQuery to replace the drop down list with an auto complete text box that had the same value as the drop down list.

After finding an auto complete plugin for jQuery I was ready to implement my solution.

The first thing I did was hide the drop down list and add an input text box after it

$dropDown = $("#EmployeeDropDownList");
$dropDown.hide()
   .after("<input type='text' />");
var $autoCompleteTextBox = $dropDown.next();

I then retrieve the array of employee names from the drop down list and pass it as an argument to the autocomplete plugin

var dropDownItems = [];
$dropDown.find("option").each(function() {
   dropDownItems.push($(this).text());
});

$autoCompleteTextBox.autocomplete(dropDownItems);

I then subscribe to the blur event on the new auto complete text box to synchronize the selected value on the hidden drop down list with the value in the auto complete text box

$autoCompleteTextBox.blur(function() {
   var textBoxValue = $autoCompleteTextBox.val();
   $dropDown.val(textBoxValue).attr("selected", "selected");
});

And finally I validate the value in the text box is the selected value in the drop down list when the submit button is clicked.

$("#SubmitButton").click(function(e) {
   var textBoxValue = $autoCompleteTextBox.val();
   var selectedValue = $dropDown.find("option:selected").text();
   if (textBoxValue != selectedValue)
   {
      alert(textBoxValue + " is an invalid selection");
      e.preventDefault();
   }
});

I am still pretty amazed by how simple and succinct jQuery is. It was actually really fun to learn and play around with and I look forward to using jQuery in the future.

I am seeing things from a birds eye view but I want to start seeing things up close and truly understand subjects I am studying. It’s often been said that the best way to learn something is to teach it. And one way to teach is to write blog posts, so I am going to write blog posts on the subjects that I am currently studying to help me more fully understand.

So what subject am I going to start studying? Software design principles. It’s something not taught in school and yet is what separates the good coders from the bad.

Here’s to studying to learn…

Another sentence from the post that irritates me is the following: “One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project.” Really? So we should all code like we did in college and never get better? There’s a reason for the complication in some code… it’s because it makes it easier. Easier to maintain and easier to add enhancements. So what if it’s complicated. Learn it. I’m not going to write simple software just so the average joe can understand it. I’m going to write software that’s easy to maintain and easy to add enhancements, and that often means the code can become somewhat complicated.

Now that I went on my rant, I do think there is some good in Joel’s post. I think some programmers, myself included, like creating huge frameworks that will clean the dishes and do the laundry, but often times it is overkill and not needed. But that should not be an excuse to write half-ass code either.

var mappings = AutoPersistenceModel.MapEntitiesFromAssemblyOf();
mappings.CompileMappings();
mappings.WriteMappingsTo("SomeDirectory");

Of all the classic mistakes, the most frequent one is having an overly optimistic schedule where not enough time is given to complete a project. As I reflected on this it didn’t take me long to realize that it is also one of my personal classic mistakes.

In my first job I didn’t have much control of this mistake. Upper management personnel were the ones that set the deadlines for projects, and although my teammates and I regularly fought back and said we needed more time, the deadline was rarely extended. We were always able to meet the deadline, but many times we spent the next two to four weeks working out the bugs that were missed, and it didn’t make a good impression on our clients.

Currently I’m working at a place where I’m the only software developer, and although I am now the one that sets the schedule, I find that I also have the tendency to be overly optimistic on the deadlines, and I don’t have anyone to blame but myself. So I got to thinking why I have the tendency to be overly optimistic on project deadlines.

One of the causes I’m most prone to use is thinking in terms of how long it will take to create a working prototype of the application instead of creating production ready code with test coverage and clean, organized code. Many times I can get an application up and running within a day or two, but it doesn’t have any unit tests and the code is sloppy. It can take another week or two to clean up the code and write unit tests to get it production ready.

Another reason I find myself making overly optimistic schedules is because I base the schedule out of being able to work on it full time. However, I’m never fully able to actually work on the project full time because I get pulled into other projects and tasks.

I love playing with new tools and libraries, but I find that they are also another cause for this classic mistake. Tools usually save time on a project, but the learning curve when first learning a tool can drastically add time to the project, and I often times forget to factor in the learning curve time when deciding on deadlines. /For example, NHibernate has been a great tool I use and saves a ton of time, but the learning curve is large and it took me quite some time before I was up to speed with it.

I often like to think that I’m too good a software developer to fall into making classic mistakes, but it is evident that I’m not much different from others and have the same tendencies. But now that I know this mistake is one of my weak spots, hopefully I can be mindful of it in the future and not fall into making the same classic mistake.

I must admit I have lost the “fun” in programming lately and desire to get it back. One thing I’ve always wanted to do was be part of an open source project but I’ve been too timid to do so. I’ve also been overwhelmed by all the open source projects and not knowing which one I should commit to. So this past weekend I committed to working on the Fluent NHibernate project. This project allows you to make NHibernate mappings in the code, where it is compile-safe and has refactoring ability, instead of using the hbm xml files. I’ve used it in a couple of my projects and its fluent interface is very welcomed over the xml files.

So here’s to having fun programming once again.

private int GetLargeEmployeeCount()
{
  return 200;
}

public Company[] GetLargeCompanies()
{
  IExcelRepository repo = new ExcelRepository("companies.xls");
  var companies = from c in repo.WorkSheet()
                  where c.EmployeeCount >= GetLargeEmployeeCount()
                  select c;

  return companies.ToArray();
}

Let’s take a quick look at the created ExpressionTree.

Now let’s look at the method that handles getting the value from the GetLargeEmployeeCount() method. The SQLExpressionVisitor class is responsible for converting the ExpressionTree created from the Linq statement into the SQL statement that will be used. SQLExpressionVisitor inherits from the common ExpressionVisitor class to aid in walking through the ExpressionTree.

The pertinent node that deals with the GetLargeEmployeeCount() method is highlighted in blue above. The return value from GetLargeEmployeeCount() is retrieved in VisitMethodCall().

protected override Expression VisitMethodCall(MethodCallExpression m)
{
  if (m.Method.Name == "Where")
  {
    _sql.Append(" WHERE ");
    this.Visit(m.Arguments[1]);
  }
  else if (m.Method.Name != "Select")
  {
    object methodObject = ((ConstantExpression)m.Object).Value;
    object methodValue = m.Method.Invoke(methodObject, GetMethodArguments(m.Arguments));
    _params.Add(new OleDbParameter("?", methodValue));
    _sql.Append("?");
  }
  return m;
}

VisitMethodCall() is responsible for dealing with ExpressionTree nodes that contain method calls. It turns out that the where in a Linq statement is actually a method call, so we append a “WHERE” to the string sql statement. _sql is a private StringBuilder object that is used to construct the sql statement based on the ExpressionTree.

But the code we’re really interested in is contained in the else if code block. The select Linq statement is also a method call and we’re not interested in that, so we ignore it in the else if condition.

Now we’re interested in getting the return value of the method. Let’s take another closer look at the Expression node for the GetLargeEmployeeCount() method.

This node contains all the information we need to use reflection to get the method return value. The first thing we need to do is get the object that contains the method, which we can get from the m.Object property with some casting of types.

object methodObject = ((ConstantExpression)m.Object).Value;

Now that we have the method object, we can use reflection to invoke the method and get the return value. I first tried to use type reflection to invoke the method.

object returnValue = methodObject.GetType().InvokeMember(m.Method.Name, BindingFlags.InvokeMethod, null, methodObject, GetMethodArguments(m.Arguments));

However, this only works when the method is public. If it isn’t then a MissingMethodException is thrown. Of course, only being able to use public methods is not acceptable, so we need to use Invoke() on the MethodInfo object to invoke the method.

object returnValue = m.Method.Invoke(methodObject, GetMethodArguments(m.Arguments));

The rest of the code block (_params and _sql) deals with generating the sql from the ExpressionTree.

One last point of interest is the GetMethodArguments(). This is a helper method that takes ReadOnlyCollection<Expression> and returns an array of corresponding objects. You can check it out in the SQLExpressionVisitor class if you’re interested in its implementation.

It turns out that it only takes a couple lines of code to get the return value for a method used in a Linq statement, but I spent a couple hours researching how to do it, so hopefully this article will be of help to others who are creating custom Linq providers.

<property name="dialect">
  NHibernate.JetDriver.JetDialect, NHibernate.JetDriver
</property>
<property name="connection.driver_class">
  NHibernate.JetDriver.JetDriver, NHibernate.JetDriver
</property>
<property name="connection.connection_string">
  Provider=Microsoft.Jet.OLEDB.4.0;Data Source=db1.mdb
</property>

But when I started up NHibernate, I received the following error:

System.IO.FileNotFoundException: Could not load file or assembly ‘NHibernate.JetDriver’ or one of its dependencies. The system cannot find the file specified.

File name: ‘NHibernate.JetDriver’

It turns out I needed to add the NHibernate.JetDriver DLL to the project. This DLL is not part of the main NHibernate project. It is located in the NHibernate Contrib project on Source Forge.

Building the NHibernate.JetDriver

1. Checkout the source code from Source Forge
   1. url: https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk
2. Build the NHibernate.JetDriver project
   1. Directory Location from trunk: /trunk/src/NHibernate.JetDriver
   2. The easiest way to build it is using the NAnt script included in the project (default.build)
      1. the NAnt script creates a “build” folder and places the driver in there
   3. You can also open the project and build it from there
      1. The driver will be located in: NHibernate.JetDriver\bin\Debug

Once you create the NHibernate.JetDriver all you need to do it copy it to your project directory and reference it from your project and then you should be good to use MS Access with NHibernate.

INTJ - The Scientists

The long-range thinking and individualistic type. They are especially good at looking at almost anything and figuring out a way of improving it - often with a highly creative and imaginative touch. They are intellectually curious and daring, but might be pshysically hesitant to try new things.

The Scientists enjoy theoretical work that allows them to use their strong minds and bold creativity. Since they tend to be so abstract and theoretical in their communication they often have a problem communcating their visions to other people and need to learn patience and use conrete examples. Since they are extremly good at concentrating they often have no trouble working alone.

I would have to say that description fits me pretty well.