Good Code — Bad Code
What is a good code and how can we write a more object oriented code?
Sometimes I heard my team members complaining about the quality of code which I wrote, so I started a search for some instructions about “What is a good code?”
I went through “Refactoring by Martin Fowler”, “Head first Design Patterns from O’Reilly press” and some “Articles on internet by Robert C. Martin“ and found some useful tips.
So before going through those tips, let’s start with what is bad code?
The most common criterion which is responsible for bad design(in real life) is “TNTWIWHDI” means “That’s not the way I would have done it” so this should not be a criteria for declaring a code piece be bad code. But the main criteria should be
a) Rigidity: — It is hard to change because every change affects too many other parts of the system.
b) Fragility: — When you make a change, unexpected parts of the system break.
c) Immobility: — It is hard to reuse in another application because it cannot be disentangled from the current application.
d) Viscosity: — It’s hard to do right things but easy to do wrong things.
For avoiding above causes and writing good code experts have accumulated 10 OOAD (Object orientation analysis and design) principles.
1) Open Closed Principle (OCP): — Code should be open for extension and close for modification.
2) Liskov Substitution Principle (LSP): — Every function which operates upon a reference or a pointer to a base class should be able to operate upon derivatives of that base class without knowing it.
3) Dependency Inversion Principle (DIP): — High level modules should not depend upon low level modules. Both should depend upon abstraction. Abstraction should not depend upon details. Details should depend upon abstraction.
4) Interface segregation Principle (ISP): — Client should not be forced to depend upon interfaces that they do not use. Many client specific interface are better then one general purpose interface.
5) Release Reuse Equivalency Principle (REP): — The granule of reuse is the granule of release. Users will be unwilling to use the element if they need or forced to upgrade every time author changes it.
6) Common Closure Principle (CCP): — Classes those changes together belong together. The more packages that change in any given release, the greater the work to rebuild, test and deploy the release. So they should be grouped together.
7) Common Reuse Principle (CRP): — Classes that are not used together should not be grouped together. A dependency upon a package is a dependency upon everything in the package. When a package changes, and its release number is bumped , all clients of that package must verify that they work with the new package even if nothing they used within package actually changed.
8) Acyclic Dependencies Principle (ADP): — The dependencies between packages must not form cycles.
9) Stable Dependencies Principle (SDP): — Depend in the direction of stability. A package with lots of incoming dependencies is very stable because it requires a great deal of work to reconcile any changes with all the dependent packages.
10) Stable Abstraction Principle (SAP): — Stable packages should be abstract packages. The SAP I sjust a restatement of the DIP. It states that the packages that are most dependent upon (i.e. stable) should also be most abstract.
And then I found one more principle in Head First Design Principle,
11) Hollywood Principle (HP): — Do not call us, we will call you. Low level components may attach a high level component but high level component control “When and how”. Low level component should not call any methods of a high level component.
So I think that if we all try to follow these principles then our code quality will be much better and easy to maintain.
And one more thing most of these experts were convinced that a code following all the principles of OOAD is not possible but we should try to follow most of them until there is a suitable reason for not following any.
