Uncle Bob Martin incornicia il principio di singola responsabilità come "una classe dovrebbe avere solo una ragione per cambiare".
Mi chiedo, esiste un nome per un principio di conversazione come: "un singolo motivo per cambiare dovrebbe avere un impatto solo su una classe"? In altre parole, non è necessario apportare modifiche sparse su più funzioni, classi, file e così via per raggiungere un obiettivo.
Ci ho pensato spesso, ecco i miei pensieri.
In primo luogo, probabilmente stai scavando troppo in profondità in questo modo di dire. È fondamentalmente un dettaglio di implementazione di un principio più fondamentale chiamato coesione .
... cohesion refers to the degree to which the elements inside a module belong together.1 In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class’s methods and data themselves.
Ci porta al primo punto: dovrebbe esserci un solo scopo. Il secondo è più sottile. Si tratta di conformare un nome di classe alle sue responsabilità. Il livello di astrazione di questi due deve corrispondere. Ad esempio, ecco la responsabilità di Car dal mio punto di vista:
class Car
{
public function __construct()
{
}
public function drive()
{
//
}
}
Non mi interessa come guida esattamente. Come viene dato il carburante a un motore. Quindi probabilmente la seguente implementazione viola SRP:
class Car
{
public function __construct()
{
}
public function drive()
{
//
}
public function giveFuelToEngine()
{
}
}
Questi sono solo diversi livelli di astrazione. Di qui diversi motivi per cambiare. Quindi, se una classe è coesa, se esiste un unico scopo di livello superiore, se le sue responsabilità sono conformi al suo nome, l'SRP verrebbe naturalmente. SRP è solo una conseguenza pratica, non è un obiettivo da solo. L'oggetto corretto che identifica e conferisce responsabilità è
In secondo luogo, queste due frasi hanno intenzioni diverse. A class should have only one reason to change riguarda una classe che dovrebbe essere coesa e servire un solo obiettivo, che potrebbe servire come motivo per il cambiamento di una classe. Altrimenti, a single reason to change should impact only one class è circa, beh, quella ragione. Quale dei milioni di motivi sceglieresti? Che dire di "Beh, lo sviluppo del gioco non è dove la nostra azienda ha avuto successo, iniziamo un pub"? È un valido motivo per cambiare una singola classe? Se pensi che fosse eccessivo, ok, prendi il commento di Emerson Cardoso. Quindi il tuo framework può gestirlo? Ok, e se interessa diversi sistemi distribuiti? Servizio di BI, servizio di marketing, email di notifica del cliente, ecc.? In ogni caso, questo semplice cambiamento potrebbe comportare cambiamenti nella logica aziendale che nessuno dei framework è in grado di implementare automaticamente.
Quindi il mio punto è che questo detto può essere giusto o può essere sbagliato - dipende dal livello di astrazione della ragione.
Quindi, avvolgendolo, posso dire che il mio obiettivo sono classi coesive che implementano i corretti livelli di astrazione. SOLID è solo una conseguenza implementativa semplificata dei principi OO fondamentali. È solo una forma, non un'essenza.
Leggi altre domande sui tag solid