Utilizzo del modello di progettazione dell'adattatore per un microservizio dell'applicazione di notizie

0

Attualmente sto sviluppando il backend per un'applicazione di notizie, che recupera notizie da vari aggregatori (ad esempio Feedly). Ho pensato che questo fosse un buon esempio per il modello di progettazione dell'adattatore, quindi ecco cosa ho fatto:

Ho creato un file di configurazione che contiene tutte le informazioni rilevanti su ciascun aggregatore, incluso il suo adattatore

return [
    'news-api' => [
        'url' => 'https://newsapi.org/v2/',
        'api-key' => env('NEWS_API_KEY'),
        'name' => 'News API',
        'adapter' => 'NewsApiAdapter'
    ],
    'feedly' => [
        'url' => 'https://cloud.feedly.com/v3/',
        'api-key' => env('FEEDLY_API_KEY'),
        'name' => 'Feedly',
        'adapter' => 'FeedlyApiAdapter'
    ],
];

Ho creato un'interfaccia che ogni adattatore deve implementare

interface NewsInterface
{
    public function fetchNews() : array;
}

E poi ho messo tutto insieme e l'ho usato così

public function handle()
{
    foreach ($this->config as $config) {
        $adapterClassName = 'App\Adapters\' . $config['adapter'];
        $adapterClass = new 
        $adapterClassName($this->client);
        $adapterClass->fetchNews();
    }
}

Ora, le mie domande sono le seguenti:

  1. Si tratta di un caso utile per il modello di progettazione dell'adattatore?
  2. La mia attuale implementazione utilizza effettivamente il modello di progettazione dell'adattatore?
  3. Esiste un altro paradigma di progettazione che è più adatto a risolvere questo problema?
posta user3010617 16.12.2018 - 11:53
fonte

1 risposta

1

Se stai implementando la tua interfaccia esattamente come ne hai bisogno per ogni implementazione, allora non considererei esattamente la tua soluzione Modello adattatore , piuttosto semplice polimorfismo.

In termini di suggerimenti per soluzioni migliori, un paio di cose:

  1. Passare il nome della classe come una stringa e quindi concatenarlo al pacchetto e usare quella variabile per istanziare la classe mi sembra molto "hacky". Se si desidera mantenere tale modello, suggerirei di passare \Your\Package\YourNewsApiFetcher::class nei dati di configurazione.
  2. Il modello di osservatore mi sembra la soluzione naturale per risolvere questo problema. Essenzialmente ha una lista di "osservatori" che ascoltano "eventi" che possono essere "pubblicati" / "sottoscritti a". Nel tuo caso, vorrei che le tue comuni figlie di Api pubblichino un evento ogni volta che tirano le notizie più aggiornate, e il tuo gestore (o "osservatore") si iscriverebbe a quegli eventi e li gestisse comunque è necessario.
risposta data 18.12.2018 - 00:58
fonte

Leggi altre domande sui tag