Dependency Frameworks and Parameterized Constructors

April 23rd, 2012 Comments

Most dependency injection frameworks support some kind of object initialization through parameterized constructors. The question is whether or not it’s a good idea to use that feature of DI frameworks.

Consider the following code:
Read more…

The Castle Project

August 17th, 2007 Comments
Castle Project

In the last couple of years I have noticed a steadily growing interest in the .NET community around the Inversion of Control (IoC) and Dependency Injection (DI) patterns.  This is partly due to the fact that a number of excellent frameworks have emerged and gained popularity that allow us to use these designs in our applications relatively painlessly.  One such framework is the open source Castle Project.  In my opinion Castle is the best implementation of IoC and DI among many others that I have come across including Spring.NET, NInject, and ObjectBuilder.  This is however my opinion; which framework you use largely depends upon your requirements and your preferences.

If you are just getting started with Castle or are curious about why the heck one should use IoC and DI, I strongly suggest you check out the 3-part article series by Simone Busoli.  I just came across these articles and I can’t stress enough how well they are written.

ISP: Interface Segregation Principle

August 28th, 2006 Comments

The Interface Segregation Principle (ISP) deals with cohesion and is closely related to the Single Responsibility Principle (SRP). In Uncle Bob’s terms, the ISP states that:

Clients should not be forced to depend on methods that they do not use.

In other words, this principle states that if a class performs multiple functions that may be used by different client classes, then those functions should be seperated out into different interfaces according to their usage.

The idea behind this principle is to confine the aount of rework to only clients that use a certain interface, should the interface of a depended-upon class changes.

DIP: Dependency Inversion Principle

August 27th, 2006 Comments

The Dependency Inversion Principle deals with how to correctly design classes such that their dependency on one another causes the least amount of work in case of a change. Uncle Bob’s definition of DIP states:

  • High-level modules should not depend on low-level modules. Both should depend on abstractions.
  • Abstractions should not depend on details. Details should depend on abstractions.

Essentially what this principle means is that in a tiered design, higher level modules and lower level modules should not directly depend on each other; instead they should only depend on abstractions. Moreover, abstractions should not have any knowledge of details (other classes in the system).

This principle closely relates to some of the other design principles I discussed previously in that it yields a design that is highly decoupled ensuring that minor changes in one part of the application do not cause a domino effect in other parts of the application. Moreover such a design is extensible — as new business entities are added, usually such as design scales well by requiring only new code to be added rather than existing code to be modified. ASP.NET 2.0′s Provider Model is a great example of such a design that provides a default implementation for various sub-systems such as Membership, Personalization, Navigation, etc. but also allows developers to modify the default behavior by extending certain classes.