Tutti i metodi di una classe dovrebbero essere allo stesso livello di astrazione?

2

Ho una classe APIClient (solo un nome di esempio) che ha i metodi

  def get(url, params={})
    @last_response = conn.get(url, params)
  end

  def post(url, params={})
    @last_response = conn.post(url, params)
  end

  def put(url, params={})
    @last_response = conn.put(url, params)
  end

  def delete(url, params={})
    @last_response = conn.delete(url, params)
  end

Questi metodi possono essere utilizzati per fare qualsiasi cosa sull'API, ma in seguito ho aggiunto altri metodi che implementano attività più specifiche che desidero fare nella mia applicazione.

Alcuni di questi nuovi metodi sono

add_category(name)

list_products

find_category_id(name)

Questi metodi forniscono un'interfaccia di livello molto superiore rispetto ai metodi get, post, put ed delete.

In vari punti ho visto il commento che le istruzioni in funzioni / metodi dovrebbero essere tutte allo stesso livello di astrazione ma non ho visto lo stesso detto per i metodi in una classe.

Mi sbaglio nel mettere questi metodi di alto livello nella stessa classe dei metodi di basso livello? A causa di ciò, si verificheranno dei problemi e c'è un modo migliore per farlo?

    
posta Qwertie 05.12.2017 - 02:30
fonte

3 risposte

4

Sì, in generale, una singola classe dovrebbe esistere a un singolo livello di astrazione. Avere più livelli di astrazione tende a violare il Principio di Responsabilità Unica. E semplicemente attaccando alle operazioni, puoi costruire una sorta di Oggetto di Dio, abbattendo la coesione della classe. E virare sui metodi è praticamente la definizione di una violazione di Open Closed Principle.

Tutto ciò detto, ci sono spesso preoccupazioni pratiche molto importanti in casi come questo. Qualsiasi tipo di operazione eseguita tramite più chiamate CRUD avrà problemi di concorrenza e transazionali (o richiederà alcuni scomodi trucchi per l'implementazione specifici). La memorizzazione nella cache e la registrazione coesiva possono essere problematiche. Le opzioni di autorizzazione sono limitate se si desidera che un utente sia in grado di apportare alcune modifiche ma non altre. A seconda dell'implementazione, potresti limitare le tue opzioni sulla quantità di dati da recuperare.

Come ogni linea guida, è un'idea che ti aiuta a fare la cosa giusta nella maggior parte dei casi, non una regola per impedirti di sbagliare.

    
risposta data 05.12.2017 - 04:24
fonte
4

Il problema numero uno qui è che APIClient è un nome terribile. Senza un buon nome il tuo codice diventa struttura, non intento. Senza questo è difficile dire quale dovrebbe essere l'astrazione.

Un nome, una classe, un oggetto, un metodo dovrebbero essere un'astrazione di un'idea chiara. Non solo un certo livello. HTTP , Category e Product sembrano buone astrazioni. Potrebbero non essere tutti allo stesso livello ma quando li usi non devi mescolarli insieme.

Questo potrebbe sembrare il suo lato che fa passi avanti. È. Dovresti anche tu. Quando puoi. Perché si tratta di qualcosa di più della complessità strutturale. Si tratta di comunicare con gli umani in un chiaro vocabolario. Ma se non puoi allora si. È meglio non mescolare insieme diversi livelli di astrazione.

    
risposta data 05.12.2017 - 04:10
fonte
0

Se stai scrivendo un piccolo programma con una squadra molto piccola, puoi probabilmente farla franca combinandoli, ma sono d'accordo con gli altri poster che probabilmente non serviranno a farti andare avanti.

La domanda qui riguarda la conoscenza del dominio (come nel dominio della materia). Idealmente, avresti due livelli di questa API:

  1. Un'API CRUD - potenzialmente generata tramite un EF -, che puoi esporre allo sviluppatore back-end, in modo che possa codificare le regole aziendali in un livello di regole aziendali, armato con la sua conoscenza di come funzionano gli aggiornamenti CRUD e che tipo di impatto potrebbero esserci sull'integrità referenziale , prestazioni, ecc. Il suo compito sarà quello di esporre un'API aziendale che nasconda tutti i problemi di rappresentazione e imponga la convalida e l'integrità, ed esegue operazioni di database efficienti basate sulla sua conoscenza della struttura del database e degli indici disponibili.

  2. Un'API aziendale, che puoi fornire allo sviluppatore front-end, con la certezza che abusare dell'API aziendale non causerà dati danneggiati (supponendo che il primo sviluppatore abbia eseguito correttamente il suo lavoro). Non vuoi dare a questo ragazzo l'API CRUD - la sua esperienza è in HTML e CSS, non i dettagli del tuo sistema. Se gli hai dato accesso all'API CRUD, potrebbe facilmente / accidentalmente bypassare le regole di business e finirebbe a mettere dei rifiuti nel tuo database.

La separazione in questo modo migliora anche il tuo profilo di sicurezza, dal momento che non esponi l'onnipresente API CRUD al sito web. Il livello aziendale può imporre autorizzazioni / titolarità / rivendicazioni e negare le chiamate in base alle esigenze, probabilmente sulla base di un contesto di sessione utilizzando la propagazione del contesto.

    
risposta data 05.12.2017 - 04:32
fonte

Leggi altre domande sui tag