Devo avere una classe con più variabili e una variabile TYPE o alcune sottoclassi?

-1

Sto sviluppando un'applicazione di tracciamento dei veicoli basata sul web. I clienti acquistano dispositivi GPS e l'azienda per cui lavoro li monta sui loro veicoli. Il client ottiene quindi un nome utente e una password per il software e questo è il modo in cui è in grado di monitorare la sua flotta.

Tuttavia, quando la compagnia ha iniziato a crescere alcuni clienti vogliono montare dispositivi GPS su forme statiche che non sono VEICOLI! Altri clienti vogliono essere in grado di elencare tutte le loro unità di flotta all'interno del software EVEN se non hanno acquistato un dispositivo GPS per loro ma vogliono semplicemente essere in grado di inserire alcuni dati che non sono correlati al tracciamento.

Quindi devo migliorare il software per poter gestire le unità fittizie e le piattaforme in cui le posizioni non cambiano.

Quindi ecco la mia domanda:

Dovrei avere poche classi come:

Veicolo (id, maxSpeed, Canbus, FuelTankCalibration, AnalogSonda, GpsDevice .....)

StaticPlatform (id, Location, AnalogSonda, GpsDevice ....)

DummyVehicle (id, MetaData, .....)

o una grande classe

FleetUnit ( Tipo , id, maxSpeed, canBus, FuelCalibration, AnalogSonda, GpsDevice, Location, MetaData, .....)

e basato sulla variabile Tipo (VEHICLE, STATIC_PLATFORM, DUMMY_VEHICLE) per gestire le varie situazioni?

    
posta Papa-rapa-beo 10.10.2017 - 15:36
fonte

1 risposta

3

Per capire quali di questi approcci hanno merito per il tuo dominio, devi capire come queste entità verranno utilizzate. Vale a dire devi esprimere alcuni requisiti .

Molti si concentrano sull'implementazione DRY , che è ottima; tuttavia, preferisco guardare prima alle astrazioni e ai concetti di dominio offerti al programmatore client consumatore (spesso tu). Quindi, vorrei prima esaminare le esigenze e gli scenari di utilizzo dei clienti consumatori, per assicurarmi che le astrazioni e i concetti di dominio che stai creando siano facili da manipolare, difficili da sbagliare e realizzare i lavori che i consumatori sono interessati a fare.

Non è chiaro se la prima opzione che stai suggerendo si riferisca a "classi separate del tutto indipendenti" o "ereditarietà dalla classe base comune (astratta)".

L'approccio "classi completamente indipendenti" è semplice; tuttavia è controindicato se si finisce per duplicare i metodi tra le due classi. Qui sto prestando particolare attenzione alle interfacce, perché per un client che consuma, l'utilizzo di classi diverse che offrono un sottoinsieme comune di metodi senza condividere un'interfaccia o una classe base, è un problema da consumare. (È probabile che anche le loro implementazioni non siano ASCIUTTE.)

Anche la "one big class" è piuttosto semplice. Qui un odore di codice è se si trovano i client che utilizzano un'istruzione switch nel campo "type" e l'involucro speciale i diversi "tipi"; usando l'ereditarietà insieme a tell-don-ask, tali possono essere ripuliti. Tuttavia, se non si ha questo odore di codice, allora questa è una soluzione appropriata. Un altro odore di codice può essere un attributo inapplicabile per determinati tipi di entità, vale a dire dove potrebbe essere necessario passare o fornire "null" nella costruzione o qualche altro valore che indica "mancante e non applicabile".

Tuttavia, anche con una nozione di StaticPlatform, una posizione segnalata GPS può avere senso; può essere applicabile e, non è necessario annullarlo. Uno StaticPlatform può essere spostato una volta tanto anche se non è un veicolo. Con piattaforme non statiche, una data posizione di casa può avere un senso. Quindi, forse una posizione di casa e una posizione GPS segnalata possono avere un senso per tutti i tipi.

L'uso dell'ereditarietà è un po 'più complesso e potrebbe effettivamente essere eccessivo o YAGNI. D'altra parte, potresti avere casi in cui la differenziazione / specializzazione è molto utile.

Inoltre, non dimenticare che puoi sceglierne uno e un refattore se trovi difficoltà nell'usarlo o qualche odore di codice. Dopo tutto questo è ciò che rende il software "soft".

    
risposta data 10.10.2017 - 18:59
fonte

Leggi altre domande sui tag