Assorted OOD Principles - Introduction

Recently I have presented a tech talk to my team on assorted object oriented design principles (in C++). Here is an attempt to reproduce it in a better shape (my apologies to the concerned, if due acknowledgments were missing).

Issue: Software has behavior; it can suffer from aging and starts emitting smells

Aim: Control the direction of Software's behavior (i.e make it behave as intended and not the other way)

Our job is to get to know and benefit from well known, widely used design principles (we can find counter arguments too).

These principles are expected to help us

• keeping the software correct, simple, stable, reusable, extendable …
• reducing the learning curve for new comers, thereby saving $ for the company
• feel proud thyself for delivering a great piece of software

Covered principles

• Open Closed Principle (OCP)
• Single Responsibility Principle (SRP)
• Liskov Substitution Principle (LSP)
• Dependency Inversion Principle (DIP)
• Interface Segregation Principle (ISP)
• Law of Demeter of Methods (LoD)

What goes wrong with Software?

• People
• A piece of code is the reflection of a person/team/organization
• Any piece of software reflects the organizational structure that produced it (Melvin Conway)

• Changing requirements (key cause)
• Either we fix things or add behavior (call it enhancements)
• Not all systems are designed/modified with further change in requirements in mind
  

• Poor dependency management (very crucial design aspect)

As a result, Software starts emitting smells

• Rigidity: making simple changes becomes hard, re usability decreases

• Fragility: trivial changes cause the system to break in strangest places

• Immobility: changes require major re-factor rather constant minor (simple) modifications/enhancing
  

• Viscosity: doing things right becomes hard hence people start hacking (which may not preserve the design)
  
• Viscosity of environment (confine changes to avoid tedious processes)
• Viscosity of Design (choosing a simple hack over complex but correct solution, breaks the design)
  

In short: Aging code looks complex and un manageable (or simply call it LEGACY)