Been a long while since I have posted on my blog, hope you are all well. Thought i’d share some knowledge and in particular design principles to make your code more usable, extensible and test-ible!
Btw, if you feel that you need certain aspects of programming explaining then give me a shout via the contact page. Also, stay tuned as I will post a series of blogs where I will show you, step by step, how to build an application with the fundamentals of object-oriented programming.
[ S ] Single Responsibility Principle
Do one thing and Do it well!
The single responsibility principle is a computer programming principle that states that every module/component/class should have responsibility over a single part of the functionality provided by the software.
[ O ] Open Closed Principle
Be Open for extension, Closed for modification!
In OOP, the Open/Closed Principle states that ‘software entities’ (classes, modules, functions, etc) should be open for extension, but closed for modification; an entity can allow its behaviour to be extended without modifying its source code. If it is open for modification, you run the risk of unattended side affects – bugs in your code.
[ L ] Liskov Substitution Principle
Derived Classes Can Stand In for Base Classes
Programming to an interface provides the correct structural trait for the Liskov Substitution Principle. The Liskov Substitution principle was introduced by Barbara Liskov in her conference keynote “Data abstraction” in 1987. A few years later, she published a paper with Jeanette Wing in which they defined the principle as:
Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.
But let’s be honest such a mathematical representation of a principle might be necessary but it wouldn’t be entirely helpful for our daily work as software engineers.
The principle basically defines that objects of a base class shall be replaceable with objects of its subclasses without breaking the application.This means the objects of your derived classes will need to behave in the same way as the objects of your base class.
[ I ] Interface Segregation
The interface segregation principle states that no client code object should be forced to depend on methods it does not use. This basically means that each client code object should only implement what it needs & not be required to implement anything else.
Interface segregation principle is all about having lots of small, focused interfaces that define only what is needed.
Note: Put your interfaces on a diet, don’t feed them burgers!!
[ D ] Dependency Inversion
Dependency Inversion is based upon [ O ] and [ L ] and the general idea of this principle is as simple as it is important: high level modules, which contain complex logic, should be easily reusable and unaffected by changes in low-level modules, which contain utility features.
To achieve this you will need to introduce an abstraction that decouples the high-level and low-level modules from each other. Robert C.Martin’s definition of the Dependency Inversion principle consists of two parts:
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.
High-level and low-level modules depend on the abstraction. The design principle does not just change the direction of the dependency, as you might have expected when you read its name; but, it splits the dependency between the high-level and low-level modules by introducing an abstraction between them.
SO we end up with two dependencies:
- The high-level module depends on abstraction
- The low-level module depends on the same abstraction
That is all for now… I could go on forever showing code examples but I’m not sure if that is something you guys want. Please let me know if code examples help you more to understand design principles and I will remember for future to include them.