Progettare le interazioni nella progettazione orientata agli oggetti

Question

Progettare le interazioni nella progettazione orientata agli oggetti

#1 da (3 voti)

1

Sto creando un design orientato agli oggetti per un'app di cab-call come Uber. Ho alcune delle classi elencate. Sto avendo problemi nel progettare il comportamento tra le classi. Ad esempio, ho queste due classi - Customer e Driver

Un cliente può chiamare i conducenti e un conducente può accettare una richiesta di guida dai clienti.

Quindi il mio pensiero è Customer class avrà una funzione contactNearByDrivers() . E la classe Driver avrà una funzione come getRideRequest()

Ho due domande qui -

Dove dovrebbe essere l'effettiva implementazione di contattare i driver vicini e confermare la risposta del guidatore? Il mio pensiero è che possa esistere una classe di utilità, diciamo CustomerDriverInteraction . Questa classe avrà in realtà funzioni per contattare da vicino i conducenti e registrare le loro risposte. La funzione contactNearByDrivers() in Customer class creerebbe un'istanza di CustomerDriverInteraction e chiamerà le sue funzioni. È un buon modo per farlo?
Una volta che un autista accetta una richiesta, il cliente e il conducente devono essere collegati insieme per una corsa. Dovrebbe esserci un'altra classe chiamata Ride ? La classe Ride avrà un Customer e Driver oggetti come membri, tra gli altri campi. Questo approccio è corretto? Quali sono i modi migliori per progettarlo?

object-oriented architecture object-oriented-design

posta nishant 11.01.2017 - 06:32

fonte

1 risposta

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

Trova duplicato in un elenco di un elenco di numeri interi MIT, BSD, licenza Apache: crea un'applicazione per client

score 3 · Accepted Answer

Il tuo primo problema può essere risolto aggiungendo un'altra astrazione per un "headquarter operativo", consente di chiamare la classe Headquarter . Questo può prendere la responsabilità di contattare i driver, ma non sarebbe una "classe di utilità" e non verrà istanziato da contactNearByDrivers . Invece, sarebbe istanziato solo una volta, sarebbe tenuto informato sulla posizione di tutte le auto, e ogni cliente può tenere un riferimento al quartiere generale per chiedere lì per ottenere un passaggio.

Alla tua seconda domanda: questo dipende dai casi d'uso che vuoi supportare con il tuo modello. Se il tuo unico caso d'uso è "trova un'auto gratuita per un cliente che si trova nelle vicinanze", non è necessaria una classe Ride . Ma se il tuo intento è quello di scrivere un programma che può effettivamente calcolare il conto per un giro, o fa un po 'di contabilità sulle corse che sono state eseguite in passato, allora probabilmente ne hai bisogno.

Consiglio vivamente di farlo in modo incrementale. Non modellare troppe di queste classi "in anticipo". Cerca di implementare effettivamente un caso di primo utilizzo come "Registri di driver / annullamenti di registrazione presso il responsabile principale" - avrai solo bisogno di due delle classi per questo. Nella prossima iterazione, implementa il caso d'uso "il cliente chiede al proprietario di un posto di guida" - e scopri quali sono le classi necessarie per l'implementazione. Il test del lackmus se hai modellato le classi giuste e, se le hai modellate correttamente, è se ti aiutano a implementare il tuo programma, e se il modello alla fine non contiene nulla di cui il tuo programma in realtà non ha bisogno.