December
30

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.

Subclassing

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.

Instantiation

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

Missing User

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.

Conditioning on Instantiation

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.

kick it on DotNetKicks.com

6
December
27

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?

kick it on DotNetKicks.com

2
March
5

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.

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:

  1. Object Oriented Programming,
  2. What design is,
  3. Separation of Concerns,
  4. Liskov Substitution Principal,
  5. The .NET Framework (3.5),
  6. A whole bunch of BCL,
  7. C#,
  8. Relational databases & SQL,
  9. Active record & SubSonic,
  10. MVC,
  11. Dependency Injection & Inversion of Control,
  12. Test Driven Development & MbUnit,
  13. Mocking with Rhino Mocks,
  14. Design patterns,
  15. Scrum,
  16. Continuous integration,
  17. Source Control Management with Subversion,
  18. Tools.

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.
kick it on DotNetKicks.com

6
March
16

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/

0
February
24

A nice set of articles regarding non-collection related Generics development.

Part 1 discusses an elegant way to perform Lazy Load to a type. ( my personal favorite )
http://honestillusion.com/blogs/blog_0/archive/2006/10/02/Generics-without-Collections.aspx

Part 2 introduces a way to filter collections.
http://honestillusion.com/blogs/blog_0/archive/2006/11/07/Generics-without-Collections-_2800_pt-2_2900_.aspx

Part 3 shows a way to parse strings into Enum values.
http://honestillusion.com/blogs/blog_0/archive/2006/11/20/Generics-without-Collections_2C00_-Pt.-3.aspx

0
February
19

We use the Strategy pattern all the time (some knowingly and some by some sort of fluke).

Here is a nice a way to implement Strategy without the overhead of interfaces. It’s a bit anti-OO, but is useful when there is no concrete need to create a new type just to perform some logic.

http://www.lowendahl.net/showShout.aspx?id=115

0
February
15

TDD Anti-Patterns

Posted In: Patterns, TDD by rauchy

Unless you are applying design techniques to your unit tests, they can become quite messy. In such cases, being familiar with these anti-patterns can help you stay away from trouble.

http://blog.james-carr.org/?p=44

0
February
15

I really love Martin Fowler’s architecture patterns. Here is an article covering a few basic patterns from his fascinating book - Patterns of Enterprise Application Architecture.

http://www.evanhoff.com/archive/2007/02/14/Basic-Application-Patterns-Transaction-Script-Domain-Model-and-Table-Module.aspx

0
February
15
0
February
15

The Specification Pattern

Posted In: C#, Design, Patterns by rauchy

A very handy pattern. Well, maybe not that handy, but still neat.

http://devlicio.us/blogs/jeff_perrin/archive/2006/12/13/the-specification-pattern.aspx

0