2015-11-23 10 views

risposta

14

Il fatto che siano entrambe le interfacce non li rende più uguali rispetto a se avessimo due classi.

I contratti sono generalmente il termine utilizzato per fare riferimento alle interfacce che forniscono un limite stretto tra alcune funzionalità nel codice utente e il chiamante/client. Il contratto è un modo per applicare un'interfaccia coerente alla funzionalità. Come regola generale, una volta definito un contratto, non dovrebbe essere modificato. Ciò significa che è possibile implementare l'interfaccia in qualsiasi modo (o anche scambiare implementazioni diverse) ma i client utilizzeranno sempre gli stessi metodi di interfaccia. La modifica dell'implementazione non avrà alcun impatto sul codice client. I valori sottostanti sono direttamente influenzati dalle definizioni dei contratti.

Una facciata d'altra parte è un modo per semplificare alcune funzionalità del codice al client. Penso che molte delle facciate di laravel (come Route e Request) siano effettivamente mappate su molte classi/interfacce diverse. Ti fa risparmiare dover ricordare quale delle classi fa quale lavoro: basta chiamare la facciata e lasciarla gestire.

Il motivo di progettazione di facciata è spesso utilizzato quando un sistema è molto complesso o di difficile comprensione perché il sistema ha un numero elevato di classi interdipendenti o il suo codice sorgente non è disponibile. Questo modello nasconde le complessità del sistema più grande e fornisce un'interfaccia più semplice al client. wikipedia

Mentre penso che laravel usi le interfacce con le facciate, le interfacce non definiscono le classi sottostanti. In effetti, è probabile che se una firma del metodo delle classi sottostanti cambia, probabilmente riscriverebbe la facciata come simile. Una facciata non riguarda la stipula di un contratto rigoroso, si tratta di semplificare le cose.

UPDATE Come correttamente identificato nel tuo commento, laravel Facciate hanno metodi statici. Puoi facilmente chiamarli nel tuo codice senza doverli iniettare (anche se dal punto di vista del test, questa è una pessima idea). Il fatto che le facciate di Laravel siano statiche è una scelta di implementazione di Laravel (risale a L3 dove tutte le classi laravel erano statiche) e non ha nulla a che fare con la definizione rigorosa di facciate.

Forse la risposta alla tua domanda è questa: le facciate sono un retaggio di L3. Ci sono molti post sul blog per e contro l'uso di classi statiche da parte di Laravel. Penso che alla fine il team di sviluppo di laravel abbia deciso di offrire entrambe le opzioni.

Mentre Ho fornito la definizione rigorosa dei contratti e facciate in precedenza, magari in laravel la semplice differenza è che facciate sono classi statiche e contratti sono implementati da classi istanze. Questo quindi mantiene tutti felici.

Dalla documentazione laravel

laravel "facciate" servono come "proxy statico" ad sottostante classi nel contenitore di servizio, fornendo il beneficio di un conciso sintassi espressiva pur mantenendo maggiore controllabilità e flessibilità che statico tradizionale metodi.

+0

È la stessa cosa in cui definisco le facciate nella mia app, quindi sarà facile tipo suggerimento come usare Auth; che è facile da usare in tutti i metodi di una classe, quindi se usiamo i contratti dobbiamo usare illuminate/contracts/mailer quindi iniettare sui metodi così ogni volta che abbiamo bisogno di scrivere queste cose e iniettare –

+0

Laravel ha appena definito di averne definito facciate con tutti i metodi statici (risale a laravel 3). Una facciata per definizione non deve avere metodi statici, ma solo Laravel ha deciso di implementarla in questo modo. –

+0

penso che sia il più confuso di tutti in laravel –