S.O.L.I.D.

I’m not gonna touch it

S.O.L.I.D

Single ResponsibilityOpen-ClosedLiskov SubstitutionInterface SegregationDependency Inversion

Robert C. Martin

Single Responsibility Principle

Class should have one, and only one, reason to change.

Single Responsibility Principle

Adherence to the SRP helps to improve maintainability. When object encapsulates multiple responsibilities changes to the object for one of responsibilities can negatively impact the others.

Single Responsibility Principle

Object role stereotypes:● information holder● structurer● service provider● controller● coordinator● interfacer

Single Responsibility Principle

Violations:● create user and send email in one class● struts action class that handles two

pages/dialogs

Open-Closed Principle

Class should be open for extension, but closed for modification

Open-Closed Principle

The reason is that if you modify a class, you’ll likely break the API/Contract of the class, which means that the classes that depend on it might fail when you do so. If you instead inherit the class to add new features, the base contract is untouched and it’s unlikely that dependent classes will fail.

Open-Closed Principle

Violations:● if/else, switch statements● modify 3rd party lib sources

Liskov Substitution Principle

Subtypes must be substitutable for their base types

Liskov Substitution Principle

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of the program.

Any method that takes class X as a parameter must be able to work with any subclasses of X

Liskov Substitution Principle

This isn’t always possible to avoid LSP violations.Mitigating strategies:● TDD● Design by Contract● Favor object composition over class

inheritance

Liskov Substitution Principle

Violations:● Rectangle example● .NET 2.0 Collections (IsReadOnly)

Interface Segregation Principle

Client should not be forced to depend on an interface that it does not need/use

Interface Segregation Principle

Large interfaces make it harder to extend smaller parts of the system.

Many client-specific interfaces are better than one general-purpose interface.

Interface Segregation Principle

Violations:● empty method● method throws exception

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend upon abstractions.

Abstractions should not depend upon details. Details should depend upon abstractions

Dependency Inversion Principle

Instead of lower level modules defining an interface that higher level module depend on, higher level modules define an interface that lower level module implement

Dependency Inversion Principle

Violation:

Dependency Inversion Principle

Solution:

Other principles?

DRY/DIEKISSYAGNI

Alternative?

SingletonTight couplingUntestabilityPremature optimizationIndescriptive namingDuplication

Questions

?