MSDN Magazine - October 2008 - (Page 43) Jeremy miller Patterns In PractIce Cohesion And Coupling Much of software design involves the ongoing question, where should this code go? I’m constantly looking for the best way to organize my code to make it easier to write, easier to understand, and easier to change later. If I structure my code well, I’ll go on to fame and glory. Structure it badly, and the developers who follow me will curse my name for eternity. In particular, I would like to achieve three specific things with my code structure: 1. Keep things that have to change together as close together in the code as possible. 2. Allow unrelated things in the code to change independently (also known as orthogonality). 3. Minimize duplication in the code. To achieve these three goals, I need some tools to help me know where new code should go and some other tools to help me recognize when I’ve put code in the wrong place. By and large, these goals are closely related to the classic code qualities of cohesion and coupling. I achieve these goals by moving toward higher cohesion and looser coupling. Of course, first we need to understand what these qualities mean and why coupling and cohesion are helpful concepts. Then I’d like to discuss some of what I’m going to call “design vectors” that help us move toward better structures and recognize when we need to move away from bad structures that have crept into our code. Just as a note, I’m the primary developer of an open source inversion of control (IOC) tool called StructureMap. I’m going to be using some real-life examples from StructureMap to illustrate the design problems that these vectors address. In other words, don’t make the same mistakes that I made. Figure 1 Tightly Coupled Code public class BusinessLogicClass { public void DoSomething() { // Go get some configuration int threshold = int.Parse(ConfigurationManager.AppSettings["threshold"]); string connectionString = ConfigurationManager.AppSettings["connectionString"]; string sql = @"select * from things size > "; sql += threshold; using (SqlConnection connection = new SqlConnection(connectionString)) { connection.Open(); SqlCommand command = new SqlCommand(sql, connection); using (SqlDataReader reader = command.ExecuteReader()) { while (reader.Read()) { string name = reader["Name"].ToString(); string destination = reader["destination"].ToString(); // do some business logic in here doSomeBusinessLogic(name, destination, connection); } } } } } Decrease Coupling You can’t help but hear the terms “loose coupling” or “tight coupling” in almost any discussion on software design. Coupling among classes or subsystems is a measure of how interconnected those classes or subsystems are. Tight coupling means that related classes have to know internal details of each other, changes ripple through the system, and the system is potentially harder to understand. Figure 1 shows a contrived sample of a business-processing module that is very tightly coupled to various other concerns besides the business logic. Let’s say that what we really care about is the actual business processing, but our business logic code is intertwined with data- access concerns and configuration settings. So what’s potentially wrong with this style of code? The first problem is that the code is somewhat hard to understand because of the way the different concerns are intertwined. I’ll discuss this further in the next section on cohesion. The second problem is that any changes in data-access strategy, database structure, or configuration strategies will ripple through the business logic code as well because it’s all in one code file. This business logic knows too much about the underlying infrastructure. Third, we can’t reuse the business logic code independent of the specific database structure or without the existence of the AppSettings keys. We also can’t reuse the data-access functionality embedded in the BusinessLogicClass. That coupling between data access and business logic might not be an issue, but what if we want to reSend your questions and comments to mmpatt@microsoft.com. October 2008 43
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.