SDLC – Software Development Lifecycle … flashback, component-level design principles (part 9 of many)

Article
03/07/2009

Continued from SDLC – Software Development Lifecycle … testing, the moment of truth (part 8 of many). I have always been a very practical person, focusing on the task at hand out of intuition, experience and principles that my mentors pounded into me many, many years ago. Paging through the book “Software Engineering A Practical Approach”, I stumbled over a section that caught my eye. The main reason why I stopped was because I read “four basic principles…”, which was followed by seven principles … my brain said 4 != 7, my Swiss genetic material went into a mental spasm and I therefore sat down and read through the section … which turned our quite interesting.

Let me summarise the four + three principles mentioned, as I am sure that some of you have not heard of all seven either.

Principles

Open-Closed Principle

Martin R., states that “a component should be open for extension, but closed for modification” in “Design Principles and design patterns”, which you can peruse at https://www.objectmentor.com. In my terminology it states that we must design components to enable others to re-use and extend the functionality thereof, without caring about, or knowing about the internal organs of the component. In other words, not only must we put great care into the component interface design, but also the documentation thereof.

Liskov Substitution Principle

In the same publication, Martin R. states that “subclasses should be substitutable for their base classes”. This implies that any sub-classed component must inherit and honour all implied contracts. As shown in the following diagram, a component that uses a specific base class will therefore continue functioning when using a derived sub-class … in fact the component should typically neither know nor care.

I used rough pseudo code, so do not mentally compile the code. In (1) we create an instance of a BaseClass object, passing it to the Base Class User component in the Call() operation, which merely expects the IContract contract. In essence the principles states that (2) is also a feasible option. Option (2) instantiates an instance of object of type SubClass(), which inherits and implements the IContract contract. The Call() operation will continue to work, whether we use option (1) or (2).

Dependency Inversion Principle

According to Martin R., the dependency invention principle states that “depend on abstractions, not on corrections”. We can achieve this principle by relying on abstract contracts (interfaces), not on concrete component implementations. If we hide the concrete implementations, we can extend the overall design and the inner organs of the black-boxed components.

Interface Segregation Principle

For this principle Martin R. suggests a number of things, such as packaging principles, but this principle is primarily focused on the principle of “many client-specific interfaces are better than one general purpose interface”. For the simpler minded people, like I, it means … I think … to create specialised interfaces serving specific requirements, rather than finding the mother of all interfaces, that will service the universe.

General purpose … not recommended	Specialised … recommended

Release reuse Equivalency Principle

According to Martin F., this principle defines that “the granule if reuse is the granule of release”. While designing for reuse is not rocket science, it introduces both a solid technical design and an effective versioning and packaging strategy. Contracts are guaranteed and the developer of a reusable component and its contract, commits to a versioning and release strategy that will not only deliver and support new features, but maintain a solid backward compatibility.

Common Closure Principle

Classes and components that evolve and change together, are family and belong together, especially in terms of packaging.

Common Reuse Principle

The last principle that Martin R. refers to states that “class that aren’t reused together, should not be grouped together”. If everything is group as one monster package, any changes to the smallest citizen within the package, forces us to deploy another monster package. The common closure and common reuse principles are closely related and in my humble opinion we are striving for a packaging and deployment strategy which keeps only related components together.

How many of the four + three did you know? So what is next in the SDLC series? Who knows, but watch the space, because we may stumble over something interesting again soon q:-)