SE principles

Summary

Principles

Concept

Single Responsibility Principle(SRP)

• a class should only have one responsibility
• it should only change if there is a change to that responsibility
• that way when something needs to be changed, only one class needs to change

Open-Closed Principle(OCP)

• make a code entity easy to adapt and reuse
• reuable without having to modify the entity itself
• open for extension but closed for modification
• similar to the command pattern, separate specification from implementation

Liskov Substitution Principle(LSP)

• derived classes must be substitutable for their base classes
• subclass should not be more restrictive than the behaviour specified by the superclass

Staff#adjustMySalary - works with all +ve values
Admin#adjustMySalary - works with all -ve and +ve values
Academic#adjustMySalary - only works with 1..100

• Admin - follows LSP, substituting it for Staff will not break any functionality in Payroll
• Academic - violates LSP, will not work for some values that Staff allows

Interface Segregation Principle(ISP)

• no client should be forced to depende on methods it doesn’t use
• interface that the client depends on should be as lightweight as possible

Dependency Inversion Principle(DIP)

1. high level modules should not depend on low level modules, both should depend on abstractions
2. abstractions should not depend on details, details should depend on abstrations

• neutral interface that the concrete class(details) can inherit from, and that the higher level module can depend on

SOLID Principles

• SRP
• OCP
• LSP
• ISP
• DIP

Separation of Concerns Principle(SoC)

• improve modularity by separating code into distinct sections
• each section addresses a separate concern
• concerns - set of info that affects the code of the program:
  • specific feature
  • specific aspect - eg. security
  • specific entity
• reduces functional overlaps among code sections
• limit ripple effect when changes are introduced
• higher cohesion with lower coupling

Law of Demeter(LoD)

• entity should have limited knowledge of other entities
• entity should only interact with objects that are closely related to it
• method m in object O should only know:
  • object O
  • objects passed as arguments to m
  • objects created in m (directly or indirectly)
  • objects from the direct association of O

void foo(Bar b) {
    Goo g = b.getGoo(); // G is a stranger, not created by foo
    g.doSomething();
}

YAGNI Principle

• you aren’t gonna need it!
• do not add code just because it might be useful later
• cannot predict what will be needed in the future, so no point doing extra work

DRY Principle

• don’t repeat yourself
• every piece of knowledge must have a single unambiguous representation in a system
• don’t duplicate information/functionality

Brooks’ Law

• adding people to a late project will only make it later
• additional communication overhead will outweigh the benefits of adding extra manpower