I was in the middle of a TDD coaching session a couple of days ago when it hit me - people need a tool that will help them write one assert at a time!
So I started looking for one, and after about 2 exhausting minutes of trying to Google it, I gave up and wrote one myself.
Give it a try at http://www.rauchy.net/oapt.
Following my post on the Special Case pattern, I just wanted to give a few more examples in which the pattern proves to be really helpful. In the previous post, we talked about using the Special Case pattern when returning collections, but you can use it in other places as well.
Suppose we have a cached collection of User objects, and we want to fetch a specific User and save it to the database.
User user = cache.Get(”John”);
if (user != null)
{
user.Save();
}
If we subclass User with a class called MissingUser, and have our cache object return it when it can’t find a user, we can reduce our calling code to:
User user = cache.Get(”John”);
user.Save();
MissingUser.Save() overrides User.Save() and does nothing.
Side note: we could definitely go with checking cache.Contains(”John”), and acting on the result, but I think this is too much detail for this level of abstraction, and may be violating Tell, Don’t Ask.
Suppose we want to display a User’s profile. Our User class has a string called Name and a bitmap called Picture.
User user = profiles.Get(”Mark”);
if (user != null)
{
this.Name = user.Name; // Binding is for the weak.
this.Picture = user.Picture;
}
When a User is not found in the profiles repository, we could make it return an instance of the regular User class, where User.Name = “Not Found”, and Picture is something like
This way, we can just write:
User user = profiles.Get(”Mark”);
this.Name = user.Name;
this.Picture = user.Picture;
and a profile will always be displayed.
What if we wanted to check if a User exists in a managers repository, and only if it is not found, fetch it from a clerks repository? One might be tempted to write something like:
User user = managers.Get(”Ahmed”);
if (user != null)
{
// Ahmed is a manager.
Display(user);
}
else
{
// Ahmed must be a clerk.
user = clerks.Get(”Ahmed”);
Display(user);
}
In the previous examples, we avoided the conditional (null check) by using Special Case. If you look at the requirement for this example, you’ll see that the conditional is built into it, and there is no way to get around it.
But if we use the same technique we used in the second example, we could create an instance of User, that has a boolean property called Exists, which will be populated according to the result. This way, we could express our condition much better:
User user = managers.Get(”Ahmed”);
if (user.Exists)
{
// Ahmed is a manager.
Display(user);
}
else
{
// Ahmed must be a clerk.
user = clerks.Get(”Ahmed”);
Display(user);
}
No code saved here, but our intention is much clearer this way.
What the hell is a “if (user != null)”? English, people.
Guys, will you knock it off with returning nulls from methods? You should return Special Cases, not nulls! nulls tend to bypass any polymorphic structure, and cause code to be cluttered with null checks. For example:
public IEnumerable<Picture> GetAllPictures()
{
if ( .. there are pictures .. )
{
return pictures;
}
else
{
return null;
}
}
Oh boy, users of this method would have to check for nulls every time before they operate on it: (if they don’t they might get a NullReferenceException, which s-uhhh-cks)
var pictures = GetAllPictures();
if (pictures != null)
{
foreach (var picture in pictures)
{
…
}
}
Isn’t that null check a big distraction from the actual logic? If you use a Special Case for that enumerable and return Enumerable<Picture>.Empty(), the calling code could be reduced to:
var pictures = GetAllPictures();
foreach (var picture in pictures)
{
…
}
Much better, no?
A hallway talk at the Alt.NET Israel Unconference got me thinking about coding standards in general, and naming conventions in particular.
I’ve seen dozens of holy wars regarding the subject of naming conventions - when a project starts, when a new team member comes along, when the team leader is replaced etc.
I used to think that a project should have a single naming convention, and everyone should follow it. Now, I’m not so sure any more. I mean, what is really so important about naming conventions? What makes a project with a unified naming convention better than a project without one?
The first argument for naming conventions is always unity. You want all your data members to look the same.
But, think of it, what is really that important about unity? What business value do you get from it? Does it cut down development time? Does it improve performance?
IMO, if one developer wants his field to be called “_identifier”, another wants “m_identifier” and the other wants “nIdentifier”, just let them! No one ever died from Hungarian notation or a “m_” prefix, I believe.
For those who still believe in Hungarian notation (or any of its siblings), readability seems to be a great argument for naming conventions.
However, Hungarian notation might have been a good argument a decade ago. Today, all IDE’s provide great intellisense, and one could determine the type of a member in a second by hovering on it.
Determining the scope of a variable (method or class) is important, but can also be easily discovered by intellisense.
I’m not trying to say you shouldn’t have a naming convention in your project. I’m just trying to say, don’t let it bother you so much.
Set up a naming convention at the beginning of the project, have your team members agree on it, but don’t hunt down any exception and have it fixed.
Write a unit test or get a cup of coffee instead.
Do you think naming conventions are important? Where would you draw the line?
Krzysztof Cwalina, author of the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries has released a second revision of the Framework Design Guidelines Digest.
I’ve read Framework Design Guidelines a couple of years back and learned a whole lot from it. It definitely makes it to my top 5.
However, I’ve had problems convincing my staff members to read it, as it contains~400 pages of design tips, which are quite hard to read in succession.
The Framework Design Guidelines Digest narrows the basics down to 9 pages. I recommend everyone to download and read it every once in a while.
Quoting Krzysztof:
This document is a distillation and a simplification of the most basic guidelines described in detail in a book titled Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. Framework Design Guidelines were created in the early days of .NET Framework development. They started as a small set of naming and design conventions but have been enhanced, scrutinized, and refined to a point where they are generally considered the canonical way to design frameworks at Microsoft. They carry the experience and cumulative wisdom of thousands of developer hours over several versions of the .NET Framework.
Get it here.
I found myself in an interesting coaching spot - I am going to teach Alt.NET to a programming infant. I’m going to create the first Alt.NET baby.
Real life sometime brings you to strange situations. I lead a development team which is building a web application and we recruited a new member a couple of weeks ago. I’ll refer to him as “the baby”, since he never wrote a single line of code.
Why is he on board, you ask? Well, he’s a fresh computer science student and knows his way around the presentation side of websites (good knowledge of HTML, CSS, Javascript and good ol’ web black magic) so this seemed like a good trade-off for both sides - the baby will join the team and help us out with his mighty presentation powers and in exchange will be part of a real project for the first time and will get on-job-training.
This is an interesting spot. Computer science has brought his knowledge to a certain level so far (basic C) and I need to catch him up with:
Oh, and this needs to be done as we go on with the project.
Can you think of anything I forgot to mention?
Does the order make sense or would you suggest a different one?
Eeek.
Over the past few years I found myself training several fresh computer science bachelors and introducing real world software engineering to them.
The easy cases were those who came by with a submissive approach and accepted just about any methodology I suggested. The hard nuts could be divided into multiple groups, but the hardest of them all were those who thought that design is unnecessary.
I’ve seen several pieces of fresh meat who thought that there is no real reason to model your application into classes, modules, components or layers. They’ve learned how to program in C back in college, and were certain that once you have a requirement you can start writing lines and lines of code.
Personally, I don’t feel comfortable giving orders to people on such issues. I can’t just force them to design, because I think you must believe in what you do and if you get an order from your boss to design, you will do it poorly and without putting your heart into it.
I’ve tried several approaches to convince these tough nuts, from lectures on different kinds of ilities to giving them small projects and changing requirements upon completion.
These seemed to have little effect as my students had quickly forgotten or ignored them. They insist that they can develop just about any application in a single class.
The best way I’ve found to open up their eyes was using what I refer to as the tree & wind analogy:
I simply take a student to the nearest window and point at the nearest tree, I ask him what kind of behaviour he sees. I tell him I see a tree, who’s leaves are being blown away by the wind. I try to make him understand that even in nature, there is no such thing as “just logic” and there is no behaviour in the world that is not related to an object.
Usually, after understanding this they start listening.
Having been involved in test-driven projects over the past 2 years, I found myself explaining the advantages and disadvantages that test-driven introduces to software projects to many people whom I taught, trained or coached.
I always stuck to the usual points, for instance, “design by usage”, “safety-net for your code”, “faster drilling to the heart of the problem”, “provides documentation for your code” etc. These are all great advantages for the project, and everyone in the project (including management) eventually enjoys them.
Lately I have been asking myself – why is TDD good for me? How do I profit from it? What’s in it for me? And most important: Why do I deliberately get myself into TDD adventures and even dare to say that I enjoy it?
Well, the answer is simple: Test Driven Development allows me to be an idiot, and keep getting paid for it.
When writing code, I face two tightly-related problems: Functional requirements (making sure my code does what it’s supposed to do) and design requirements (making sure the code is simple, efficient, coherent, extensible etc.).
Solving both these problems is a big headache, and I often find programmers failing to provide a solution for both of them. I often find poorly designed code which answers its requirements or well-designed code which does not.
TDD allows me to split this headache into two manageable problems.
Following the Red-Green-Refactor mantra carefully, I start with writing horrible, horrible code which answers the requirements. I continue making it all the way to the green stage and continue iterating until I have a hefty, sloppy method which answers all its requirements.
From that moment on, I do not need to worry about the functional requirements any more as my code is already obliged to solve them by unit tests, and any slight shift from that obligation will immediately come to my attention.
This is the part the real fun sets in. I have the freedom to design (actually, redesign) without worrying about breaking functionality. Like a lucid dream, you can do whatever you want, without the risk of getting hurt.
This way I can concentrate on each phase separately:
When answering requirements, I just have to make sure the code does what it is supposed to do, even at the price of code duplication, inefficiency and plain ol’ dumb code.
When refactoring, I have a well-set environment that allows me to apply design techniques without worrying about functionality.
This raises a question – can the role of the modern developer be split to two as well? A less-experienced developer will handle functionality and a more experienced developer will refactor?
If you liked this article, 
The article discusses the crooked way that the Singleton pattern is used in many software systems. I’ll admit it - I made this mistake many times.
If I have to choose one thing to take along from this article, it is that Singleton should not be applied freely on types which access is to be restricted to, but only for those rare cases which the type models a real world restricted object, like a class which encapsulates access to a configuration file or a queue.
Certainly, Singleton should not be applied to every stateless class, use static classes for that.
http://aabs.wordpress.com/2007/03/08/singleton-%e2%80%93-the-most-overused-pattern/
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| « May | ||||||
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
