Wednesday, July 29, 2009

Refactoring & Design Podcast

Here is a short podcast I participated in; the subject is Refactoring & Design.

Many thanks to Ran & Ori !!!



Sunday, July 26, 2009

One pattern to rule them all

(Cross post from IRefactor)

Well, there is none...
Simply to put, there is no silver bullet.

Yet, while designing an application, there are several well known extremes:

"Heavy weighted design" - Such a design will use almost each and every pattern described in the bible of "Design Patterns" - by the Gang of Four.

However, squeezing as much as possible patterns into your design has a bad smell. Here is what Erich Gamma has to say on the matter:
"Trying to use all the patterns is a bad thing, because you will end up with synthetic designs-speculative designs that have "flexibility" that no one needs. These days software is too complex. We can't afford speculating what else it should do. We need to focus on what it actually needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.
"Big ball of mud" or "no design" at all - Though the application utilizes classes (objects) and methods, it does it solely due to the language constraints. After all, the code must be placed somewhere and usually it lies in giant classes and methods. Besides that, there are no abstraction layers or small and specialized objects that have "concise conversations" in order to solve the business requirements.


To use the patterns correctly, a Software Engineer must understand the context (=requirements) and the suggested solutions depicted by the patterns. Usually, in the real life scenario, it's hard to grasp where exactly is the right context to which a suggested design solution should be applicable. Especially for the inexperienced Software Engineers, design patterns described by the Gang of Four's bible can confuse and lead to:
  • Misidentify contexts and thus creation of "Big ball of mud" or "no design" applications.
  • Over identify contexts (even where there is no context at all) and thus creation of "Heavy weighted design" applications.
That's where the Expert pattern can be handy! Expert pattern is one of the General Responsibility Assignment Software Patterns. In essence it's a very basic and straightforward pattern that helps to pinpoint what is the main responsibility of a method or a class. Just ask yourself: "What is the real responsibility of the method/class? Is it really this method's/class's responsibility to do that operation?". By answering those questions it's possible to divide a system effectively to a lot of small, but cohesive objects, that really need to collaborate together in order to solve your business requirements (which is what Object Oriented Design is really about).

So it comes, that though there is no "pattern to rule them all", using the Expert pattern/principle effectively, will allow you to rule your application.

Sunday, July 12, 2009

Asymmetric Accessor Accessibility and Automatic Properties

(Cross post from IRefactor)

Asymmetric Accessor Accessibility – is a feature that was introduced in .NET 2.0 in order to allow different accessibility levels to get and set portions of a property or an indexer. Those get and set portions are called accessors.

In the example below, the get accessor is public, whereas the set accessor is restricted and private.

private string id;
//...
public string Id
{
get { return id; }
private set { id = value; }
}

Automatic Properties – is a syntactic sugar feature, introduced in .NET 3.5 to allow more concise property declaration.

public string Id {get; set;}

The above features, can be combined together to form a very elegant and concise property declaration, with asymmetric accessibility levels:

public string Id {get; private set;}

Using “automatic asymmetric accessibility properties” contributes to the clarity, elegance and correctness of the code.

One of such examples is immutable class implementation.