Why do we need Software Design Principles

Object oriented software development often becomes victim of non-maintainable, unreliable etc in long run in most of cases. Lot of people might put bad coding skills behind that state (which is true sometime) but bad software design is the actual culprit which will make excellent coders write bad code because software design doesn’t allow them to do so.

Always remember knowing what not to do is more important than what to do !!!

Let’s first discuss what should be avoided at all cost while designing any software:

1. Singleton class — Although lot of people feel Singleton classes are the best method to solve major software problems. However, we should avoid using because of following reasons:
   • These classes are very difficult to manage in longer runs.
   • These classes almost always makes tightly coupled modules.
   • These classes hides the dependencies between modules which is always a No-No.
2. Tightly coupled Modules — If modification of a module affects other modules then these are called tightly coupled modules.
   • These modules becomes difficult to handle while enhancing or modifying any other modules.
   • These modules often difficult to unit test and harder to reuse.
3. Reinventing the invented and optimised pieces — Lots of tools available out there, Use them!!!
   • use tools wherever possible, avoid custom solutions for exact same thing available in open.
   • custom solutions takes lot of time to stabilize and optimize, while tools or open source libraries will always give a much needed boost.
4. Untestable code — Code should always be simple to unit tested.
   • If a module is difficult to test then this will always create un-necessary problems down the line.
   • Not writing unit test will save time only in short run but cost dearly in long runs. And it happens ALWAYS!!!
5. Premature optimisation of code — Optimisation of code/modules should happen only after certain milestones.
   • Never try to optimise the code from the first day. That should not be taken as thumbs up to write bad code.
   • Never try to kill the readability or maintainability for petty gains. These will make life harder later.
6. Non-Modular code — Function/Class should always be given one and only one job.
   • Never try to do everything in single function or class. This will lead to tight coupling.
   • This will lead into duplicate, lengthy, non-readable code.
   • Any function which is taking more than one screen or have more than 10 branches should be avoided always.
7. Bad Naming — Name of a function/class must be descriptive enough to give snapshot of its functionality to a reader.
   • Never go for a short name. Don’t afraid to give function/variable/class a name related to its function.
   • Ideally a function/class should never be looked inside just to know about its functionality. Its a MUST NO-NO.
8. Duplicate Code — A section of code repeated in multiple functions/class is called duplicate code.
   • Duplicate code almost always leads into unforced bugs as programmer mostly missed to update all the related functions.
   • Any section of code must be written only once.
   • Don’t be afraid of number of functions in the software. Create functions for every section of repeated code.

Now, that we know what mistakes leads into designing a bad software, we should see the standard object oriented design pattern used in the industry.
Standard software design principles SOLID is applicable in all object oriented programming languages and must be used for a robust software design.