Pattern di facciata o solo esporre oggetti figlio?

Naviga le tue risposte
1

Ti stai chiedendo pro e contro su un'implementazione di pattern di facciata (o forse c'è un modello migliore che dovrei prendere in considerazione), piuttosto che esporre semplicemente un oggetto dipendente a un chiamante.

Considera quanto segue: 

public class Model implements Player  {
  private Player player;

  /*
     implement Player interface, which simply delegates calls to my player object
  */
  @Override
  public void play() {
    player.play();
  }
}

vs 

public class Model {
  private Player player;

  public Player getPlayer() {
    return player;
  }
}

Analogamente a un'altra domanda qui intorno a modelli di facciate ( Esempio di esempio di facciata per principianti ) , Sono preoccupato che la mia classe Model continuerà ad estendere l'interfaccia dopo l'interfaccia, che è terribile ASCIUTTO senza guadagnare molto. Tuttavia, la mia classe del modello qui è l'oggetto del modello per un modello MVC. Vorrei che il mio controller parlasse solo con il mio modello, e non mi preoccupassi degli oggetti figlio contenuti nel modello. Quando il controller vuole che la mia app vada a play() , chiamare model.play() sembra migliore di model.player.play() .

Come il mio modello diventa più complesso, qual è il modo migliore per gestire questi paradigmi in conflitto?

    
posta gdbj 27.03.2017 - 19:48
fonte

5 risposte

1

La "Legge" di Demetra dice di usare la Facciata / Wrapper. SECCO (e pigrizia programmatore) dice solo esporre il bambino. Di solito pigro == buono.

IMO, se l'oggetto figlio (Player nel tuo esempio) è ben noto, stabile e (idealmente) un po 'astratto, come un Elenco o Stream , senza casi speciali o trucchi, basta esporlo.

Se è complicato e l'utente ha una buona possibilità di incasinarlo (diciamo che ha problemi di sincronizzazione o di validità interna) quindi proteggerlo.

    
risposta data 28.03.2017 - 03:21
fonte
1

Perché hai pensato di utilizzare il pattern di facciata in primo luogo?

Da Wikipedia :

A Facade is used when an easier or simpler interface to an underlying object is desired.

La facciata non aggiunge alcun valore se non stai semplificando l'interfaccia, ma solo delegando metodo per metodo.

    
risposta data 27.03.2017 - 20:49
fonte
1

Contro: una facciata richiede più digitazione.

Professionisti: una facciata può rendere le cose molto più semplici per il chiamante e può anche servire a impedire che eseguano azioni illegali.

Il tuo esempio è piuttosto banale, ma immagina un'interfaccia più complicata. Forse se l'input su player.Move(positionData) non è solo una semplice coordinata ma richiede informazioni sulla posizione personalizzate, ad es. un percorso in una partizione dello spazio binario . Forse non vuoi che il chiamante debba capirlo, quindi fornisci un metodo di facciata che accetta le coordinate cartesiane. La facciata può chiamare una seconda classe per calcolare il percorso BSP dalle coordinate e quindi inviare la chiamata a player.Move() . In questo tipo di configurazione, la facciata potrebbe fornire molta usabilità al chiamante, oltre a garantire che il percorso sia valido.

    
risposta data 28.03.2017 - 00:28
fonte
0

Il pattern Facade è in genere per rappresentare un sottosistema complesso in un modo più semplice per chiamare il codice che non ha bisogno di conoscere tutti i dettagli su di esso. Ad esempio, potresti avere un componente che espone dozzine di metodi, ma vuoi solo che l'interfaccia utente ne conosca 3. Forse i metodi sul tuo componente sono primitivi e l'interfaccia utente deve chiamarne combinazioni in momenti diversi. In questo tipo di casi potresti voler usare il modello di facciata, ma sembra che tu voglia qualcosa di diverso.

Che cosa stai cercando di ottenere implementando uno schema qui? Se stai solo cercando di allentare l'accoppiamento tra l'interfaccia utente e il modello, è sufficiente utilizzare semplicemente un'interfaccia. Tuttavia, non lo chiamerei modello di facciata, ma solo OOP di base.

Inoltre, tieni presente che quando si tratta di design pattern, l'uso appropriato è guidato molto dalle dimensioni del progetto, dalla complessità o da altri requisiti. Se c'è qualcos'altro che puoi dirci sulla portata del progetto, potrebbe essere molto utile per dare consigli più dettagliati.

    
risposta data 28.03.2017 - 03:05
fonte
0

In base alla risposta "Ero preoccupato per l'accoppiamento stretto tra il mio lettore e il chiamante."

The Facade Pattern non ha alcun programma nascosto. È un modello molto diretto. Rendi le tue classi di applicazione più facili da usare per il codice "utente".

Il modello di facciata non ha lo scopo di ridurre l'accoppiamento da singole classi. L'accoppiamento ridotto del codice "Facaded" è generalmente un sottoprodotto di ciò.

Per fare un esempio concreto, supponiamo che volessi comandare al mio sistema di iniziare a raccogliere dati e riportare gli eventi man mano che si verificano. Per accendere il sistema potrebbe essere necessario registrare l'interfaccia di controllo per ricevere eventi specifici, accendere un sensore o due, leggere i dati GPS, leggere le informazioni meteorologiche, posizionare i sensori, fornire letture ai moduli di elaborazione dell'algoritmo, ecc. .qualcuno di essi avrà almeno una classe che lo rappresenta. Mentre lo sviluppatore di applicazioni può sapere come mettere insieme tutti questi pezzi, lo sviluppatore povero che sviluppa l'interfaccia utente avrà le mani piene per capire tutto.

IOW, questo è molto per il codice "utente" per sapere quando tutto ciò che vogliono veramente è dire StartDataCollection (). Così nasce la facciata. Tutta quella conoscenza del coordinamento delle classi per coordinare l'elaborazione è nascosta dietro quella facciata.

Se tutto il tuo sistema avrà sempre una implementazione di codice "utente" o lo stesso sviluppatore sta implementando l'interfaccia dell'applicazione e "utente", allora Facade non è probabilmente necessario e forse una sorta di Command Pattern o concetto operativo è un opzione.

Dove la Faccia brilla è quando il tuo sistema ha più tipi di interfaccia "utente" che possono controllarlo. Usando la facciata, con l'aggiunta di eventi, elaborazione asincrona, code di messaggi, forse alcune regole specifiche dell'applicazione, ecc ... e assicurando che Facade e il codice dell'applicazione siano indipendenti dall'interfaccia utente, il compito di implementare solo nuovi tipi di interfacce finisce per diventare uno dei dati di scrittura / lettura da / per l'interfaccia fisica. Fare in modo che l'app faccia le cose giuste è banale perché basta fare chiamate sulla facciata e ricevere eventi dalla facciata.

Inoltre, puoi sviluppare e testare l'interfaccia "utente" totalmente indipendente dalla tua applicazione. Anche se questo è buono di per sé, è un proiettile d'argento per rispettare le scadenze perché ora puoi lanciare più persone al problema (che non funziona quasi mai nello sviluppo del software) poiché possono sviluppare il loro software indipendentemente dagli altri e dalle interfacce utente / controllo tendono a non essere così difficili come l'elaborazione dell'applicazione principale.

Tornando alla tua domanda .... Il giocatore dovrebbe essere esposto o no? Direi che se tutti i metodi di facciata sono semplicemente rigurgitare il metodo corrispondente sulla classe, allora penso che sia necessario rivisitare i casi d'uso o la progettazione. So che hai appena dato un esempio semplice, ma in pratica quello che hai mostrato è che "Player" è davvero la facciata. L'altra opzione è che forse la funzionalità di Player.Play () appartiene alla facciata anziché a Player.

Penso che sia giusto esporre un gruppo limitato di classi in Facade per semplicità, in particolare per quanto riguarda le informazioni di reporting. Tuttavia, eviterei di esporre le classi con l'intento di avviare operazioni applicative. Creare un metodo di facciata per questo. Cosa succede se cambi la tua applicazione per consentire più utenti ma solo 1 può giocare alla volta? Se il codice "utente" ha accesso all'istanza Player, ti verrà un po 'di dolore. Se hanno solo accesso al metodo Play di facciata (), modifica il numero di utenti fino a quando il tuo cuore è soddisfatto.

    
risposta data 29.03.2017 - 00:46
fonte

Leggi altre domande sui tag

Implementazione Small Mutex? Misurare / imporre meccanicamente l'uso decrescente di un'API obsoleta nel tempo?