Design Principles And Patterns

I am dedicating this area to talk about anything related to software. My First series of posts will be related to software Architecture and Patterns.

This initial post will outline some basics principals that an architect should always have in the back of his/her mind. Then I will talk a bit about some OOD principles. As we talk about these topics, patterns, idioms and other subjects will come into play.

Bad Smells in the Code

There are certain things, “smells”, that I look for when doing code review. These smells separate good code from bad code.

• Rigid, therefore fragile. A rigid code is basically the one that is resistant to change. This is measured in terms of regression. Ex. You fix a bug here and it breaks some place else. This kind of code (with hidden dependencies) is fragile.
•  Easier to use than reuse. If you try to reuse the code in another project …. forget it !!!. The code has so many dependencies that it just does not work.
• Easier to Work around than to fix. Many times you are facing this decision: Fix a problem in a elegant way, but lots of work, or hack it. When a hack is faster to apply than the real solution, engineers tend (due to schedule pressure or pure laziness) to take the easy road. Dino Esposito and Andrea Saltarelo mention in their book (Microsoft .NET Architecting Application for enterprise). “This aspect of design –that invites or accommodate workarounds more or less than fixes – is often referred as to viscosity”. High viscosity means the software resists to changes.

Structured Design

• From Spaghetti to Lasagna code. I think this phrase says everything. Favor layered software it is reusable and modular.
• Cohesion. Measures how strongly-related and focused the various responsibilities of a software module are. Target high cohesion modules they favor maintenance and reusability because they tend to have no dependencies. read Ward Cunningham (http://c2.com/cgi/wiki?CouplingAndCohesion). “He says that two modules , A and B, are cohesive when a change to A has no repercussion for B so that both modules can add new value to the system”.
• Coupling. It measures the level of dependency existing between two software modules, such as classes, functions and libraries. Favor low coupling.

Advanced Principles

• The Open/Close Principle. The idea is simple… produce code that can survive changes. So we need some mechanism that allow us to create new code without breaking existing code that works. Basically “A module should be open for extension but closed for modification”. Every time a change is required, you enhance the behavior of the class by adding new code and never touching existing old code that works.
• Liskov’s Substitution Principle. That is an interesting one. Basically it states that “Subclasses should be substitutable for their base class”.

I am getting tired of writing so on the next article I will continue the discussion on software design. I will concentrate on Design patterns and code testability.

Cheers