Funzionalità di separazione in un'app di consegna cibo

Question

Funzionalità di separazione in un'app di consegna cibo

#1 da (5 voti)

3

Sto creando un design orientato agli oggetti per una semplice app attraverso la quale gli utenti possono ordinare cibo dai ristoranti. L'utente può sfogliare ristoranti nelle vicinanze, esplorare il menu, aggiungere articoli al carrello e infine checkout.

Per ora mi concentro su due classi principali User e Restaurant e l'interazione che un utente può esplorare nei ristoranti vicini. Diciamo che esiste una funzione chiamata getNearByRestaurants(Location location) . Qual è il posto migliore per la funzione? Alcune opzioni che ho pensato -

In User class. La mia confusione con questo è dovuto al fatto che la classe User abbia tutte le funzioni relative solo a un utente, come cambiare email, carta di credito, ecc. O dovrebbe avere funzioni che possono interagire con altre entità?
Una nuova classe chiamata UserActions in cui è possibile elencare tutte le interazioni dell'utente con altre entità.
Una classe chiamata RestaurantRegister , che può essere un singleton. Qualsiasi nuovo ristorante si registrerebbe utilizzando le funzioni di questa classe. getNearByRestaurants(Location location) può essere in quella funzione.

object-oriented design-patterns object-oriented-design

posta nishant 19.01.2017 - 21:43

fonte

1 risposta

Leggi altre domande sui tag object-oriented design-patterns object-oriented-design

Modello di dominio vs modello di presentazione e funzione generale ordina l'array multidimensionale in modo ricorsivo - è ragionevole

score 5 · Accepted Answer

Sembra che Restaurant e User siano entrambi significativi indipendentemente, quindi non avrebbe molto senso per un User includere le operazioni che riguardano Restaurant e viceversa. Inoltre, non avrebbe senso che Restaurant contenga queste informazioni, perché risulterebbe in una serie di riferimenti ciclici difficili da gestire.

L'approccio UserActions suona in un primo momento ragionevole, ma non si ridimensiona. Man mano che la tua funzionalità cresce, finirai con una classe gigantesca che include praticamente tutte le funzionalità dell'applicazione. Dopotutto, le azioni degli utenti non sono integralmente correlate alla maggior parte delle funzionalità di un'applicazione creata per gli utenti?

Un servizio con una singola responsabilità di trovare ristoranti vicino a una posizione sembra molto gestibile. Non mi fa impazzire il nome RestaurantRegister , perché in realtà non specifica le funzionalità del servizio. L'ambiguità su ciò che fa il servizio potrebbe portare il servizio a diventare il proprio tipo di servizio monolitico per aggregare tutto il comportamento Restaurant (come una piccola porzione del modello UserActions che hai descritto). Quindi, piuttosto che RestaurantRegister , potresti voler provare qualcosa di più significativo come RestaurantFinder , ad esempio.

Detto questo, penso che l'idea sia principalmente qui. Tranne che potresti non voler forzare un'implementazione singleton. Immagina di decidere di volere una funzione che filtra i ristoranti nelle vicinanze in base alle preferenze memorizzate dall'utente sul tipo di cucina che preferiscono. Sarebbe ragionevole considerare un'implementazione che può essere applicata all'utente corrente, in modo da non dover complicare l'interfaccia trasmettendo dati sulle preferenze dell'utente. Questo non sarebbe molto compatibile con un'implementazione singleton. Un altro motivo per evitare il pattern singleton è che, a seconda del linguaggio utilizzato, un'implementazione standard di Singleton può a volte porre problemi per il test.