piątek, 22 stycznia 2010

Pai Mei's Second Lesson: How to eliminate dependencies on static utility classes?

Good design is very hard to achieve. It is even harder to come up with a good design before starting to implement the application. We often end up with one big project that has lots of inner dependencies on its own classes. The problem arises when classes rely on concrete implementation of logger class or some static configuration class. Code in these classes looks like this:
public void FooBar()
    string foo = Settings.Default.Foo;
    // some code
When you need to move some logic to another project (the most common case is creating a library that implements some specific functionality), you have to break these dependencies. Unfortunately, it will take some time and you will have to change a lot of code.

However, it is possible to avoid this kind of dependencies. You could use some IoC container such as Ninject, without relying on specific implementation of utility classes. Unfortunately, you have to rely on specific IoC container. However, it is very likely that you will use the same IoC container for every project in your solution, so it shouldn't be a problem. After changing the code, it looks like this:
IConfigurationProvider configurationProvider = KernelContainer.Kernel.Get<IConfigurationProvider>();
ILogger logger = KernelContainer.Kernel.Get<ILogger>();

public void FooBar()
    string foo = configurationProvider.Foo;
    // some code
Obtaining concrete implementation this way may not be the best pattern (compared to just marking properties or constructor with Inject attribute); however, this is the easiest change to make, without the need to instantiate every class through service locator.
Relying on interfaces and not depending on concrete classes will allow you to easily extract parts of your logic to external class libraries.
This style of coding has many more advantages that will be discussed in future lessons.

It's the wood that should fear your hand, not the other way around.

czwartek, 14 stycznia 2010

Pai Mei's First Lesson: How many method parameters is too many?

Welcome to Pai Mei's programming tutorial ;)

Lesson One: How many method parameters is too many?

Many times I see people struggling with maintaining their code because they have too many method parameters. They have lots of methods that take the same list of e.g. 8 parameters, and when it comes to adding another one, they have hundreds of places to change.

If your method has up to 3 parameters, it's probably ok.
If your method has between 4 and 6 parameters, consider creating a class which holds parameters that have something in common (thus limiting number of parameters).
If your method has more than 6 parameters, you have to find a way to limit their number. Creating a parameter object (as mentioned above) is the best way to achieve it.

Sticking to these rules will help you design better methods. They will be much easier to maintain.

And one more silver bullet. If you see methods that share common list of parameters, and what is more, all parameters create one logical object, consider creating a class that implements these methods. Remove the parameters by replacing them with class properties.

These two techniques are very easy to implement and dramatically improve your code design.

Since your arm now belongs to me, I want it strong. Can you do that?