This wraps up the series of posts on SOLID Code with Emergent Design.

Dependency Inversion Principle

The SOLID principles really boil down to managing your dependencies between classes. And, by "manage", we really mean "get rid of those suckers."

Removing dependencies (aka, de-coupling) has a number of advantages. For starters, your code becomes significantly easier to understand and maintain because it is possible to understand each piece in isolation from the rest. It’s also easier to reuse your code in other applications because it’s not hopelessly entangled in your own application’s specifics. And, of course, the fewer dependencies there are, the fewer chances you have of changes to one part of the code inadvertently breaking a different part of the code.

Read More…..

This is the 5th post on SOLID Code with Emergent Design.

Interface Segregation Principle

Or, more simply…

Avoid "fat" interfaces

This principle is about breaking down our interfaces to be highly cohesive. You might have a server that provides methods to a number of different clients as such:

If one client requires changes to the server methods it calls, you have to change the server. Since all clients depend on the server, the change impacts all of them and you risk a change that should be isolated to a single client having adverse impacts on all of the clients. In other words, the above design results in unwanted coupling between the clients.

Read More…..

This is the 4th post on SOLID Code with Emergent Design.

Liskov Substitution Principle

This principle is about following good techniques for inheritance. It says code that uses the base class should not need to have different logic based upon which concrete class is used. In other words, avoid logic in the calling code that looks something like "do this unless the concrete type is X, then do this other thing…"

As an example, imagine a drawing program that uses a base class of Shape. When the program wants to draw the shape, it simply calls Shape.draw(). It does not need to know if it’s drawing a square or a circle or a rhombohedron – they’re all just shapes:

Okay, makes sense – then what’s the problem?

Read More…..

This is the 3rd post on SOLID Code with Emergent Design.

Open/Closed Principle

The idea here is that adding new features should always be able to be handled by simply adding new code. It should never require modifying existing code. The benefit is that if you can avoid modifying existing code then you can avoid inadvertently breaking existing functionality when you add your new features.

"When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad” design. The program becomes fragile, rigid, unpredictable and unreusable. The openclosed principle attacks this in a very straightforward way. It says that you should design modules that never change. When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works." – Robert Martin

Read More…..