due classi, richiamata e unità di test

Question

Ho una classe con metodi statici: questa classe avvolge chiamate alla API Twitter

In una seconda classe, ho qualche logica aziendale.

A causa del comportamento asincrono di alcuni metodi nella classe wrapper, ho difficoltà a progettare la comunicazione. Ecco quello che ho fatto:

APIManager.swift

public class APIManager { 
    class func getPermission(callback :() -> Void) { 

     let accountStore = ACAccountStore() 
     let accountType = 
     ACAccountStore().accountTypeWithAccountTypeIdentifier(ACAccountTypeIdentifierTwitter) 

     let callbackRequestAccess = { (granted: Bool, error: NSError!) -> Void in 
      ... 
      if(granted) { 
       callback() 
      } 

     } 

     accountStore.requestAccessToAccountsWithType(setAccountType, 
        options: nil, completion: callbackRequestAccess) 

    } 
} 

Welcome.swift

public class Welcome { 

    public func checkPermission() { 
     APIManager.getPermission(getTweet) 
    } 
    public func getTweet() { 
     ... 
    }   
} 

non sono sicuro che questo progetto nel giusto o meno. Non voglio avere un forte legame tra queste classi, ecco perché sto usando un callback.

Si tratta di un design classico? Inoltre, non credo che questo comportamento sarà facile da testare?

Answer 1

Si migliorerà notevolmente la testabilità non utilizzando i metodi di classe qui. Creare un protocollo TwitterConnection. Creare un SystemTwitterConnection conforme e gestire le cose tramite ACAccountStore. Creare uno TestTwitterConnection che restituisca le risposte preimpostate che è possibile configurare per il test. Puoi anche creare un KeychainTwitterConnection per gestire gli accessi su Twitter a mano senza usare ACAccountStore, o qualche altra implementazione se Apple esce con un altro modo per archiviare questi account.

Passare la connessione appropriata a Welcome quando viene creata.

Se il protocollo TwitterConnection diventa grande, si dovrebbe prendere in seria considerazione la suddivisione in su in protocolli più piccoli, come TwitterAuthenticator e TweetFetcher che gestiscono meno cose (anche se un solo tipo in realtà implementa tutti quei protocolli). Questo può rendere il test molto più semplice, consentendo ai tipi di test di implementare solo poche funzioni piuttosto che dozzine.

L'uso di chiusure è probabilmente soddisfacente, ma è necessario attenersi maggiormente alle convenzioni di denominazione del cacao. Quello che stai chiamando a callback è tradizionalmente chiamato completion. Seguirò anche le indicazioni di Cocoa su come denominare i metodi. Piuttosto che getPermission(), sarebbe requestAccessWithCompletionHandler(). Ciò aiuterebbe il chiamante a capire che ha un comportamento molto simile a requestAccessToAccountsWithType(options:completion:). Non creare un nuovo vocabolario per il chiamante.

Answer 2

https://en.wikipedia.org/wiki/Observer_pattern

Essa vi aiuterà di disaccoppiare editore evento (osservabile) e dei consumatori (Observer).
Inoltre è possibile avere un'implementazione speciale osservabile
che non si connette a nessuna parte ma notifica agli osservatori con contenuto statico.
Quindi si chiama direttamente il metodo notifyObservers per verificare il comportamento di Observers.