.net performance cribsheet

Performance is really important part of any application. Everyone wants “fast” applications. “Fast” is not the correct measurement for an application performance however it is thought to be.

Knuth “Premature optimization is the root of all evil”. This is so true. and once you design and program properly you wont really need any optimization.

Anyways. Here is a nice article you can read about .net performance. this also applies to java as well.


Configuring Structuremap with code

A small note to myself on how to configure structuremap with code, including parameter for constructor. You usually need to pass in config files to cross cutting concerns and below is how you can inject configuration to your cross cutting concern.

string config = “someconfig”;


Dependency Injection (Inversion of control) in a nutshell

There are several tutorials, and blogs writing about dependency injection, inversion of control, dependency inversion and related concepts. One of the challenge is not only the terminology but also understanding what really dependency injection is all about. For a novice developer to get into dependency injection, folks usually look for a container, use it and expect some magic to happen when they are using the container. However, that is usually not the case and there are several misuses due to not fully understanding dependency injection. It is essential to understand the concept and patterns behind dependency injection before a developer can truly implement it in the application.

First of all, you need to know that dependency injection is quite easy and straight forward. Very easy to understand even though you encounter all these complicated terminology. Moreover Dependency injection will not make your application perform faster or more efficient. But it will give you lots of flexibility for maintainability, testability, extensibility and so on.

If you haven’t read about SOLID principles in object oriented design methodology. please do so and because Dependency injection uses all these principles for a better software development experience.

Dependency Injection is NOT one of the followings, even though you can achieve them with Dependency Injection:
Late binding: even though with dependency injection, you can switch implementation very quickly at run time or compile time easily, this is not what dependency injection is all about.
Unit testing: By using Dependency injection unit testing becomes very easy. Many software companies who uses TDD, prefers using dependency injection because it makes things testable easily. But this is not what dependency injection is all about.
Object factory: dependency injection is not an object factory that you ask for instances and it provides you correct implementations. This is a very wrong assumption and many people fail to understand this. This particular pattern is Service locator which is the opposite of dependency injection.
Object container: Dependency injection is not container. Even though container are here to help us and easy the implementation of dependency injection, it is not required to use a container to implement dependency injection. If you are not using a container but implementing dependency injection, that is called poor man’s DI.

Loose coupling gives the ability for easy maintainability, extensibility and testability. We program to an interface rather than an implementation. Then we face the challenge of where do we inject the dependencies. This is usually done at composition root of the application. Thus we achieve inversion of control. This is what inversion of control is. When you inject dependencies at composition root the control is inverted.

to be continued…

SOLID Principles

In Software development there are set of principles which are called the SOLID principles. These are

  • Single responsibility principle.
  • Open/Closed principle.
  • Liskov Substitution principle.
  • Interfage Segregation Principle.
  • Dependency Inversion Principle.

Single responsibility principle:
While developing software, underlying components should have single responsibility. Benefit of this principle is loose coupling and high cohesion. The component should be specialized doing only one thing.

Open/Closed principle:
With open/closed principle software components/entities should be open for extension and closed for modification. Benefit of this principle is also loose coupling and high cohesion. Abstraction and polymorphism are the key to make achieve this principle. Imagine a method that has many if statements in it and whenever you want to add something or make a change in the logic you need to open that method and make the change. If you need to make a change you have two options. One of them is to modify the current code base, the other is to add a new method. Of course adding a small method is much more easier and flexible to add a feature. In order to build an extensible software, you need to know the domain and the business.

Liskov Substitution principle:
While developing software it is highly recommended to program to an interface rather than programming to a implementation. Also known as program to a contract. In this context programming to an interface both contains Interfaces and Abstract classes. Due to polymorphism, you should be able to substitute an implementation with another implementation due to this principle. Inheritance should be used only for substitutability.

Interface segregation principle:
while developing software we said programming to an interface is good. However, it is not quite good to make a single interface and implement that. Interface segregation suggests us that interfaces should be highly cohesive and specialized. Obviously this will provide us high cohesion.

Dependency Inversion principle:
Dependency inversion principle tells us that we should build our software depending on abstractions not implementations which will provide us loose coupling. In this context abstractions means programming to an interface, just to be clear.

This is kinda small summary about SOLID principles. There are many other principles in the same context which will be forth coming.