Devo utilizzare lo stesso oggetto per singole istanze e raccolte?

Question

Devo utilizzare lo stesso oggetto per singole istanze e raccolte?

#1 da (1 voti)
#2 da (0 voti)

4

Una delle funzioni di un'applicazione che gestisco è quella di gestire una flotta di veicoli. Ho un oggetto vehicle con il quale posso eseguire attività correlate al veicolo; getMileage() , setDriver() , ecc. Ho anche una collezione di vehicles con cui posso svolgere attività che sono correlate a più veicoli; fitWinterTyres() , updateInsurance() ecc.

Fino ad ora, quando sto creando la mia collezione di veicoli, ho utilizzato PDO::fetchAll con l'argomento PDO::FETCH_CLASS per restituire vehicle oggetti nella mia lista di vehicles . Ciò presenta dei vantaggi, poiché quando si attraversa la raccolta, posso utilizzare metodi noti per visualizzare e modificare singoli attributi in blocco.

Tuttavia, ho notato che spesso abbiamo creato raccolte in cui vengono calcolati gli attributi dei membri che sono rilevanti solo per la raccolta corrente. Ad esempio $vehicle->priority aiuta il personale a decidere quale veicolo utilizzare in base alle condizioni di tutti i veicoli in questa raccolta. Un altro è $vehicle->service_due che, quando calcolato, assicura che non tutti i veicoli siano prenotati per un servizio contemporaneamente. Per me, queste variabili calcolate dinamicamente sono ancora attributi di oggetto, ma non mi aspetto di vederle / modificarle su una singola istanza.

Inoltre, ci sono attributi che sono utili nella collezione ma ridondanti in una singola istanza. $vehicle->driver_ID è memorizzato come numero intero nella tabella veicolo nel database. Posso ottenere una raccolta separata di drivers e trovare il driver per ID o JOIN l'ID con la tabella drivers per ottenere il nome del driver e popolare l'attributo $vehicle->driver .

Infine, ci sono spesso molti attributi che non sono mai necessari in una collezione, il che mi fa chiedere quanto sia efficiente usare l'intero oggetto nelle collezioni.

È una buona pratica avere un oggetto base che è stato esteso solo allo scopo di essere membro di una collezione? Altrimenti, come dovrei farlo?!

(l'ambiente di sviluppo è php e mysql, ma suppongo che la domanda sia indipendente dalla piattaforma)

object-oriented-design patterns-and-practices

posta boatingcow 22.03.2016 - 13:07

fonte

2 risposte

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

Riferimento ai numeri ordinali estendibili Analisi orientata agli oggetti - Peter Coad / Notazione Edward Yourdon

score 1 · Answer 1

However, I have been noticing that often times we have been creating collections where we compute member attributes that are only of relevance to the current collection. For example $vehicle->priority helps staff decide which vehicle to use based on the condition of all the vehicles in just this collection. Another is $vehicle->service_due which when computed makes sure not all vehicles get booked in for a service at the same time. To me, these dynamically computed variable are still object attributes, but I wouldn't expect to view/edit them on a single instance.

$vehicle->priority dovrebbe in realtà essere sostituito da una funzione nella collezione di veicoli chiamata qualcosa come getVehicle () . Questa funzione restituirà il veicolo da utilizzare per l'attività in base all'algoritmo di priorità.

$vehicle->service_due deve essere sostituito da una variabile $vehicle->last_serviced_on . E la tua collezione di veicoli dovrebbe avere una funzione chiamata getVehiclesForService (numero). Questa funzione restituirebbe i veicoli che è possibile inviare per la manutenzione in base al ultimo_servizio_data del veicolo

In addition, there are attributes which useful in the collection but redundant in an individual instance. The $vehicle->driver_ID is stored as an integer in the vehicle table in the database. I can either get a seperate collection of drivers and find the driver by ID, or JOIN the ID with the drivers table to get the driver name, and populate the $vehicle->driver attribute.

Idealmente, dovresti gestire questa parte (dal Database agli Oggetti) tramite un ORM . Se non ne usi uno, dipende dal tuo caso d'uso, se il nome del conducente è richiesto in tutti i casi in cui si accede a un veicolo, deve essere caricato con i veicoli dal database, altrimenti può essere pigro.

Finally, there are often many attributes which are just never needed in a collection, which makes me wonder how efficient it is to use the whole object in collections.

Le lingue moderne dovrebbero mantenere solo un riferimento a un tipo complesso. In C / C ++ si potevano usare i puntatori, ma sarebbe sempre necessario un qualche tipo di collezione per mantenere gli oggetti che devono essere trattati come un gruppo.

score 0 · Answer 2

Direi che gli oggetti e le raccolte di questi sono animali fondamentalmente diversi. La gestione di una raccolta o di un pool di oggetti è diversa dalla gestione o dall'interazione con un singolo oggetto singolarmente e ognuno di essi merita la propria interfaccia, progettazione ecc.

Ad esempio, se un singolo veicolo è dovuto per il servizio è diverso dal fatto che un appuntamento di servizio può essere avuto. Queste preoccupazioni dovrebbero essere separate (SRP, singola responsabilità). Direi che un veicolo è dovuto per il servizio in base alla manutenzione e all'amperaggio di quel veicolo protocollo di servizio. Ritenerei inopportuno affermare che un veicolo è destinato al servizio solo se è possibile ottenere un appuntamento. A causa del servizio, fissare un appuntamento prima che sia in ritardo per il servizio, pianificare il servizio per una flotta di grandi dimensioni e effettivamente prendere il veicolo per l'appuntamento di servizio programmato sono compiti diversi che devono essere eseguiti al livello appropriato (il pool o il veicolo individuale).

Mi sembra che la progettazione del tuo sistema non stia dando abbastanza responsabilità al pool o alla raccolta. Inoltre, vorrei separare e progettare più oggetti di gestione che solo il pool di veicoli. Oltre vehicle e vehicles pool , probabilmente avrei un servicing manager , che gestisce (schedulazione di) appointments , ed è orientato verso la comprensione (e la raccolta) di mechanics e service bays in service locations .

Per quanto riguarda i driver, sì, fai l'approccio JOIN (rispetto al modello di informazioni persistenti), mantieni i tuoi dati ASCIUTTI, responsabilità separate e non memorizzi nella cache una copia del conducente nel veicolo.

Piuttosto che preoccuparsi dell'efficienza degli oggetti, mi concentrerei su principi di progettazione come DRY e SRP. Questi stanno dicendo che le cose si stanno fondendo e devono essere separate. Le ridondanze che stai riscontrando sono un segno che il design richiede attenzione, non solo un problema di efficienza. (L'efficienza / le prestazioni possono meritare attenzione, ma solo quando si ha una buona caratterizzazione complessiva delle prestazioni (ad es. Test) e problemi misurabili in alcune aree dovremmo provare a caching o de-normalizzare per le prestazioni. , quindi abbiamo bisogno di questi test per assicurarci che non stiamo rendendo più lento qualcos'altro.)