When I first read the “Gang of Four” book, one message in particular really hit home with me – software developers face problems, the same problems over and over again, and design patterns provide reusable solutions to those problems. And I thought “Wow! I’m a software developer. I have problems that need better solutions, bring it on!”. It wasn’t until later that the realization struck that design patterns, and their usage and adoption, are much more subtle than that.
At the beginning of my career, I was completely unaware of design patterns or SOLID principles, or even object-oriented programming. As I progressed and matured as a developer, it became obvious that I needed to find better ways to craft software. In that process I went through several stages of professional development leading to the eventual adoption and assimilation of design patterns into my coding process.
Stage 1: Denial
“Patterns? We don’t need no stinking patterns!”
Due to ignorance, inexperience, or resistance, many developers just flat refuse to invest time in learning about patterns, SOLID design principles, or the basic building blocks of object-oriented programming. This only serves to stifle their professional growth and credibility.
Stage 2: Curiosity
“So what were those design patterns you were telling me about?”
Eventually there comes a time when the tried and true methods of the novice developer run directly into a wall, or necessity leads them in search of new frontiers. The rot has overtaken the project and killed new development, created a maintenance nightmare, caused several to question their career decision, and accumulated a mountain of technical debt.
Stage 3: The Maslow's Hammer
“Get me some nails because I have a hammer, and its name is Strategy!”
New knowledge leads to excitement but can often lead to blinders. Until we’ve had time to disassemble the information, experiment with and implement it, and put in the requisite time to internalize it, the whole world looks like it fits into the (state your pattern name here) pattern.
Stage 4: Erudition
“Strategy does not work for everything. What else you got?”
Soon we realize that not all of our problems can be solved by, or forced to fit a single pattern. Now is the time for study. Not just study, but understanding, and for design patterns one of the most significant moments of eureka comes when you grasp the concept of intent. What is the intent of the pattern? What specific problem was identified as needing a solution and thus the pattern defined because of?
Stage 5: Restraint
“With great knowledge comes great responsibility”
The more seasoned pattern aficionado sparingly begins to introduce patterns that meet the specific criteria of the challenge they face into the domain. SOLID becomes more of a conscious decision. Analysis of the code and design becomes a deeper and richer experience.
Stage 6: Emergence
“First you learn the instrument, then you learn the music, then you forget all that and just play”
You have spent so much time, effort, energy, and erudition, that patterns naturally begin to find their way into your code. You still consciously recognize a Factory, Strategy, Façade, or Proxy, but it is merely an acknowledgement of its existence rather than an effort to find a place to introduce a pattern. There is a measurable change and improvement in the quality and structure of the code and the coding process.
Stage 7: Mastery
“Those who call themselves masters are not masters”
At this level, ideas flow directly from your mind to the keyboard without hesitation, without impediment, and without fear. But the master is restless and never satisfied, always evaluating and re-evaluating where he is and how he can be better every moment. The master sees the code not in terms of methods or classes but as an organic system of maintainable order.
NOTE: This is not a post about regex (if you want more info check out http://www.regular-expressions.info/ or http://www.zytrax.com/tech/web/regex.htm and http://gskinner.com/RegExr/ is a great tool for testing your regular expressions).
One of my clients called and asked me to create an auto-complete list of employee names – no problem. I cracked open the table and started looking at the data only to realize that there were names that were “not valid”, i.e., they contained invalid characters, numbers, periods, etc. When I questioned them about it, the response was “just filter those out”. Now I was ready to get to work.
Step 1, filter out all the names that begin with a number:
SELECTFirstName, LastNameFROMdbo.EmployeeWHEREFirstName NOT LIKE '1%'ANDFirstName NOT LIKE '2%'ANDFirstName NOT LIKE '3%'...ANDFirstName NOT LIKE '9%'
SELECTFirstName, LastNameFROMdbo.EmployeeWHEREFirstName NOT LIKE '1%'ANDFirstName NOT LIKE '2%'ANDFirstName NOT LIKE '3%'...ANDFirstName NOT LIKE '9%'ANDFirstName NOT LIKE '-%'ANDFirstName NOT LIKE '.%'ANDFirstName NOT LIKE ',%'ANDFirstName NOT LIKE '\%'
SELECTFirstName, LastNameFROMdbo.EmployeeWHEREFirstName NOT LIKE '[0-9-\.,\\]%'
It’s that simple!
In my case, it was the best solution for filtering out data, but you could just as easily use this technique to create complex select statements too. Give it a try and enjoy!
Phil Haack wrote an article entitled "Structuring Unit Tests" (I highly recommend reading it) and it started us talking about how we could adopt this method of test structuring in our projects. The basic structure is a test class that contains test classes for each system under test.
We are a test-first shop and use MSTest as our testing tool of choice. So, step 1, write some tests that follow the structure (I am just going to reproduce Phil’s example using MSTest):
[TestClass]
public class TitleizerTests
{
[TestClass]
public class TheTitleizerMethod
{
[TestMethod]
public void ReturnsDefaultTitleForNullName()
{
//test code
}
[TestMethod]
public void AppendsTitleToName()
{
//test code
}
}
[TestClass]
public class TheKnightifyMethod
{
[TestMethod]
public void ReturnsDefaultTitleForNullName()
{
//test code
}
[TestMethod]
public void AppendsSirToMaleNames()
{
//test code
}
[TestMethod]
public void AppendsDameToFemaleNames()
{
//test code
}
}
}
Right away we noticed two problems. When you use the keyboard shortcut Ctrl+R, C all tests in the class are run. This works great using this structure because it runs all tests in the SUT class allowing you to isolate the scope of tests to run. The problem is when you want to run all tests in the top level class. If you try Ctrl+R, C at the top level, all tests in the namespace get run. This was easily solved by creating a unique namespace for the test class to reside in:
namespace TestStructure.UnitTests.TitleizerTestContainer
{
[TestClass]
public class TitleizerTests
{
[TestClass]
public class TheTitleizerMethod
{
[TestMethod]
public void ReturnsDefaultTitleForNullName()
{
//test code
}
Now we can run all tests in the class without issue.
The second problem is code duplication. If some setup is required for my class before I can perform my tests, I have to repeat it for each class because nested classes do not have access to their parent members. Our solution to this is to make all of the children inherit from the parent test class like this:
[TestClass]
public class TitleizerTests
{
protected Titleizer target;
[TestInitialize]
public void Init()
{
target = new Titleizer();
}
[TestClass]
public class TheTitleizerMethod : TitleizerTests
{
[TestMethod]
public void ReturnsDefaultTitleForNullName()
{
//act
string result = target.Titleize(null);
//assert
Assert.AreEqual(result, "Your name is now Phil the Foolish");
}
[TestMethod]
public void AppendsTitleToName()
{
//act
string result = target.Titleize("Brian");
//assert
Assert.AreEqual(result, "Brian the awesome hearted");
}
}
This is obviously a contrived case where no actual setup is required, but now the TestInitialize method will run before each test in my child classes.
Plus the test are much easier to read:
Posts
All Comments
