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)
No comments:
Post a Comment