Pattern facciata vs SRP

Question

Nel classico modello di facciata, un singolo oggetto di solito fornisce un'interfaccia semplificata a qualcosa di più complesso.

Come la gang dei quattro metterlo (il più vicino al "ufficiale", come si arriva ...):

Facciata (185) fornisce un'interfaccia unificata per un insieme di interfacce in un sottosistema . Facade definisce un'interfaccia di livello superiore che semplifica l'utilizzo del sottosistema.

e

... una facciata semplice astrae l'interfaccia del sottosistema oggetti per renderli più facili da usare; non definisce alcuna nuova funzionalità e le classi del sottosistema non ne sono a conoscenza.

O, come Unmesh mette in https://stackoverflow.com/a/5242476:

una facciata protegge l'utente dai complessi dettagli del sistema e fornisce loro una vista semplificata di esso che è facile da usare. Scollega anche il codice che utilizza il sistema dai dettagli dei sottosistemi, rendendo più semplice la modifica del sistema in un secondo momento.

La Responsabilità unico principio ci ricorda che l'uso

una classe o modulo devono avere una, e una sola, motivo per cambiare.

Per Uncle Bob (http://en.m.wikipedia.org/wiki/Single_responsibility_principle)

Dato che una facciata, dal design, protegge l'utente da una moltitudine di "ragioni per cambiare", come possono queste due idee lavorare insieme? Non una facciata ha tanti motivi per cambiare il numero di sottosistemi da cui dipende la sua implementazione?

Answer 1

Prima di tutto,

modelli e principi - sono due cose distinte. Un modello è una soluzione comprovata a un problema, mentre un principio non è altro che una semplice linea guida.

Quindi, confrontarli sarebbe inutile, soprattutto perché si completano a vicenda nella maggior parte dei casi.

Per quanto riguarda la definizione di SRP, "Una ragione per cambiare" può essere spiegato facilmente:

Immagine se si costruisce oggetto di una macchina, che consisterebbe di motore, tipo e cose del genere. Così la costruzione di tale oggetto sarebbe simile come:

car = new Car(new Engine(), new Type()); 

Quindi, cosa succede se si desidera sostituire il motore di quella macchina? Quindi sostituirai semplicemente l'istanza di Engine. Questa è una ragione per cambiare, poiché non ne tocchi altre parti.

Per quanto riguarda le facciate, la definizione che hai fornito è troppo generica. Una facciata è solo un altro modo di avvolgere le cose che potrebbe non essere disponibile in alcuni ambienti. Semplicemente si assicurano che la tua cosa funzioni in tutti gli ambienti.Per esempio, c'è un esempio molto noto di eventi-ascoltatori in JavaScript:

function click(object, handler){ 
    if (object.addEventListener != undefined){ 
    // For major browsers 
    object.addEventListener(....); 
    } else if (object.attachEvent != undefined){ 
    // For IE < 7 
    object.attachEvent(...) 
    } else { 
    object.click = handler; 
    } 
} 

Answer 2

In sostanza, se il vostro Facciata classe implementa principio inversione di dipendenza (dipende da astrazioni, ma non su realizzazioni concrete), è non avremo bisogno di modificarlo in futuro.

eccezioni - se c'è un bug o se avete bisogno di cambiare la logica di business di facciata (ad esempio, l'interazione tra i sottosistemi che incapsula). Ma questa non è violazione SRP.

Btw, sembra implicitamente accennato nella citazione:

Facciata (185) fornisce un'interfaccia unificata per un insieme di interfacce in un sottosistema