Single responsibility principle
A class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.
Afferma che ogni classe dovrebbe avere una ed una sola responsabilità, interamente incapsulata al suo interno.
Open–closed principle
“Software entities … should be open for extension, but closed for modification.”
Un’entità software dovrebbe essere aperta alle estensioni, ma chiusa alle modifiche.
Liskov substitution principle
“Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”
Gli oggetti dovrebbero poter essere sostituiti con dei loro sottotipi (sottoclassi), senza alterare il comportamento del programma che li utilizza.
Es.1: supponiamo di avere una classe Animal e una classe Dog che estende Animal; per LSP Dog dovrebbe poter sostituire Animal senza rompere niente :)
Es.2: class Rectangle, class Square....Estensione di Open/Close principle
Interface segregation principle
“Many client-specific interfaces are better than one general-purpose interface.”
Sarebbero preferibili più interfacce specifiche, che una singola generica.
NB in JS non ci sono le interfacce!
Invece di avere una classe complessa (molte proprietà e metodi) che viene estesa da oggetti che non la usano al 100% è meglio avere una classe base più semplice e assegnare i metodi alle classi estese all’occorrenza
Composition over inheritance!
Object.assign(MyExtendedClass.prototype, newMethod)Dependency inversion principle
One should “depend upon abstractions, [not] concretions.”
Una classe dovrebbe dipendere dalle astrazioni, non dalla concrezione (accrescimento).
The dependency inversion principle tells us that we should always try to have dependencies on interfaces, not classes. It is important to mention that dependency inversion and dependency injection are NOT the same thing.
Non vogliamo dipendere da una libreria esterna quindi costruiamo un wrapper che chiama la libreria esterna. In questo modo possiamo, in qualsiasi momento, modificare il wrapper per farlo funzionare con una nuova libreria senza intaccare il codice.
Simile in Adapter pattern o Façade pattern.
https://carstenbehrens.com/dependency-inversion-principle/
In Javascript molto spesso Liskov Substitution Principle e Dependency Inversion Principle si risolvono con COMPOSITION => aggiungere funzionalità invece di ereditare funzionalità.
0 commenti