Dovremmo creare classi solo per raggruppare le proprietà

2

Sto progettando un po 'di software che si integrerà con il nostro sistema aziendale utilizzando i servizi web. Abbiamo a che fare con gli ordini di lavoro necessari per mantenere le attrezzature.

Abbiamo un po 'di disaccordo riguardo alla struttura del contratto. Ci sono due metodi al mio fianco, vorrei una singola classe di ordine di lavoro con tutte le proprietà relative all'ordine di lavoro al suo interno.

esempio (semplificato)

WO - class
  Number - property
  Description - property
  WarrantyStatus - property
  WarrantySettlementDate - property
  LabourSteps<LabourStep>[] - list property
  Children<WO>[] - list property

Da parte loro, vogliono creare una classe ordine di lavoro, ma per ciascun gruppo logico di dati, vogliono creare un'altra classe per racchiudere le proprietà.

esempio (semplificato)

WO - class
  WOHeader - class
    Number - property
    Description - property
  Warranty - class
    WarrantyStatus - property
    WarrantySettlementDate - property
  LabourSteps<LabourStep>[] - list property
  Children<WO>[] - list property

Ora avranno circa 8 classi nella definizione completa che vogliono creare tutte con alcune proprietà in ciascuna. Questo mi sembra un po 'esagerato e ha un po' di odore di codice o di anti-pattern.

Per il mio esempio, ho due classi, WO e LabourStep.

Hanno 4 classi per la stessa cosa WO, WOHeader, Warranty, LabourStep. Ci sarà sempre e solo un WOHeader per WO e lo stesso per Garanzia.

Il mio sembra molto più semplice da gestire i cambiamenti (aggiungi una nuova proprietà a WO e così via), ma è meno leggibile. Dalla loro parte, la struttura è un po 'più facile da leggere da parte di un umano, ma sembra che stia spingendo una visione logica sul contratto a cui non appartiene veramente. E aggiungere una nuova proprietà richiede potenzialmente una modifica al WO e la creazione di una nuova classe se è stato aggiunto un nuovo gruppo logico. Queste classi extra sono disponibili solo per raggruppare le proprietà.

Qual è la strada giusta da fare?

====== EDIT ==========

Frank - Sono completamente d'accordo con i tuoi pensieri ed è il modo in cui mi avvicino al mio sviluppo. Tranne in questo caso, il sistema aziendale monolitico di terze parti con cui ci stiamo integrando è stato scritto in un modo molto generico per cercare di soddisfare il maggior numero possibile di aziende. I dati sono distribuiti su tre tabelle in una mappatura uno a uno con la maggioranza in una tabella. C'è a malapena qualsiasi convalida. Non esiste il concetto di oggetto / cosa "Garanzia" in quel sistema. Le sue sole 3 proprietà contro un WO. Tutto il servizio Web funzionerà come un archivio dati, con il WO persistente nel suo complesso. per esempio. getWO () updateWO () createWO (). Non ci saranno mai metodi get / updateWarranty (). È tutto un solo blob di dati da leggere / persistere.

Da parte nostra, non usiamo mai il risultato direttamente dai servizi web, anche se sono nostri. Li convertiamo in modelli appropriati e poi li usiamo. Per noi un contratto di dati è molto diverso da un modello. Non vi è alcuna logica aziendale nel contratto di dati, è puramente un contenitore per ottenere dati da una parte del sistema a un altro senza strettamente accoppiandoli. Ciò significa che possiamo facilmente passare a un database anziché a un servizio Web e tutte le sue esigenze devono corrispondere all'interfaccia del servizio web. Questo ci consente anche di modificare i nostri modelli che possono includere anche i risultati di più servizi Web senza doversi preoccupare di limitare o modificare il formato dei contratti dati.

Quindi, quando penso in questi termini, avere i contratti di dati suddivisi in classi WOHeader o WOWarranty non ha alcun senso. Non sarà mai usato in quel modo, nemmeno da loro. È proprio lì per un bel gruppo logico di proprietà che non significano nulla da sole. Un blocco di regione attorno a tali proprietà avrebbe lo stesso effetto netto. I passaggi di lavoro ei dettagli delle attrezzature, tuttavia, hanno molto senso essere in classi separate in quanto entità separate e non solo proprietà degli ordini di lavoro.

    
posta John Petrak 14.10.2013 - 04:25
fonte

1 risposta

10

Per essere onesti, il tuo approccio è più un odore di codice per me che per il loro. Il punto di OO è che puoi suddividere il tuo "grande" ordine di lavoro in parti più piccole e più gestibili.

Non dico che il modo in cui i tuoi colleghi rompono le cose è "corretto", o il modo "migliore" - perché richiede molta più conoscenza del dominio del problema. Tuttavia, sono già d'accordo con l'elenco degli attributi che hai dato che la tua classe di ordine di lavoro è troppo grande. È fondamentale diventare presto classe di Dio .

Consideriamo un esempio in modo più dettagliato: Garanzia. Potresti pensare che "la garanzia si applica solo ai nostri ordini di lavoro, quindi non possiamo riutilizzarla da nessun'altra parte" e questo potrebbe essere vero o no. Ciò che sarà vero in entrambi i casi è che la tua classe WO avrà metodi che riguardano specificamente solo gli attributi di garanzia e sono indipendenti da un ordine di lavoro in tutto tranne il loro posizionamento all'interno di quella classe.

Con il tuo approccio, otterrai una classe che ha un sacco di metodi, che non hanno molto in comune. Semplicemente riconoscendo la garanzia come propria cosa / classe, si finisce con una classe di garanzia che è molto focalizzata, estremamente facile da capire e mantenere e tutto ciò ad un costo molto piccolo - è sufficiente un attributo di garanzia nel WO.

Una domanda di follow-up che tu o il tuo team potreste chiedere in seguito è se volete refactoring anche su un'interfaccia. La garanzia è veramente limitata agli ordini di lavoro o si verifica anche altrove? Avete davvero bisogno di esporre i metodi della classe di garanzia ai clienti della classe WO? ecc. ecc.

E un'ultima nota a margine: quando inizi con la tua idea della classe WO, spostarti verso la versione del tuo collega è una semplice questione di refactoring ( estrai la classe ) e se mostra che sei andato nel modo sbagliato con quello puoi tornare di nuovo altrettanto bene ( classe inline ). Basta tenere a mente che nessuna decisione di progettazione potrà mai sopravvivere alla prova del tempo. Tutto dovrebbe rimanere fluido e fornire la possibilità di effettuare tali refactoring, in modo da poter adattare il design quando il prossimo requisito (cambiamento) arriva dietro l'angolo.

    
risposta data 14.10.2013 - 07:24
fonte

Leggi altre domande sui tag