Leggibilità vs benefici del polimorfismo

Question

Leggibilità vs benefici del polimorfismo

#1 da (4 voti)

1

Abbiamo a che fare con molte operazioni CRUD nella nostra applicazione. Ogni tabella di database ha una o più istanze SQLContainer corrispondenti per eseguire vari tipi di operazioni. Tutti questi SQLContainer sono memorizzati in una classe helper, in modo da poter eseguire qualsiasi tipo di operazione CRUD ovunque dal programma (una volta che si ha il riferimento a quella classe helper).

Ora che la scala dell'applicazione sta crescendo rapidamente, anche questa classe di helper del database è cresciuta immensamente (5+ KLOC). La crescita di questa classe di helper è stata influenzata dal fatto che ogni SQLContainer ha un insieme separato di metodi per eseguire le stesse operazioni, ad es. se dovessi impegnare dipendentiContainer, chiameresti commitEmployeesContainer () e quindi solo la lettura del nome del metodo dà un'idea chiara dell'azione. (Si può chiamare getEmployeesContainer (). Commit (), ma eseguiamo anche alcune operazioni aggiuntive dopo il commit, come il ripristino del codice di stato del commit che è quasi lo stesso per ogni contenitore tranne per pochi contenitori)

Ora stiamo pensando di aggiungere un po 'di polimorfismo a questa classe di helper e creare metodi per scopi generali, ad es. per il commit dei record può essere usato commitContainer (getEmployeesContainer ()), ma tale polimorfismo non avrà alcuna sicurezza di tipo e se alcune tabelle avranno pochi contenitori diversi, potresti passare accidentalmente un contenitore sbagliato.

Uno dei vantaggi è che non dovrai aggiungere nuovi set di metodi quando verranno aggiunti nuovi SQLContainer e anche le modifiche all'algoritmo di commit saranno più facili da adattare.

Domanda:
Quale approccio faciliterebbe la manutenzione mantenendo la leggibilità o esiste una soluzione alternativa per questo tipo di problema?

object-oriented java readability maintainability polymorphism

posta rpozarickij 12.12.2013 - 16:35

fonte

1 risposta

Leggi altre domande sui tag object-oriented java readability maintainability polymorphism

Qual è la migliore strategia di implementazione per questo widget html + javascript? Refactoring: comportamento delle classi di utilità in un'interfaccia comune

score 4 · Answer 1

L'approccio comune a questo tipo di cose consiste nel creare una classe (il cui nome termina con DAO) con metodi di supporto statici per eseguire i metodi CRUD relativi a quella particolare tabella di database. Quella classe statica deriva da una classe statica comune con metodi protetti che assistono le classi derivate.

Ad esempio, org.project.dao.UserDAO.getByUsername("MICHAELJ") verrebbe chiamato in modo che la classe statica UserDAO possa restituire un oggetto UserEntity in base al nome utente passato. Il UserDAO chiamerebbe quindi il metodo super protetto get che passa tutte le informazioni richieste per costruire una query e restituisce un array di oggetti (array, per quando si aspettano più valori). UserDAO prenderebbe il primo, lo cast e lo restituirà al chiamante (o restituirà null nel caso in cui nessuno è stato trovato). In questo modo, non stai violando DRY, e puoi modificare tutte le letture o solo UserDAO semplicemente modificando il metodo appropriato.

Se intendi utilizzare un'istanza (ad esempio, se desideri conservare le informazioni sulla connessione al database), va bene, ma non puoi accedervi in modo globale come stai facendo ora. Devi passarlo nelle classi che lo richiedono, il che significa che dovrai modificare tutte le classi che attualmente usano la tua classe helper.

Quindi, di solito faccio un passo ulteriore e creo una classe User che prende come unico argomento costruttore, un'istanza UserEntity . Nel mio programma userei User per ottenere e impostare informazioni e occuparmi delle sottigliezze e della convalida dei dati. In questo modo, se UserEntity fosse mai cambiato, non avresti bisogno di cambiare UserDAO a meno che non fosse un campo chiave e probabilmente dovresti fare poco più di aggiungere un getter e setter a User lasciando il resto invariato. La classe User sarebbe l'unica classe a interfacciare direttamente con UserDAO , e quindi anche questa è facile da correggere quando necessario.

Sebbene questo pattern Façade sia facoltativo, trovo che rende il mio programma molto flessibile e facilmente mantenibile, pur mantenendo la sua leggibilità. Spero che questo aiuti!