Sto avviando un progetto di gruppo scolastico in Java, utilizzando Swing. È una semplice interfaccia grafica per l'app desktop Database.
Il professore ci ha dato il codice del progetto dell'anno scorso in modo da poter vedere come fa le cose. La mia impressione iniziale è che il codice è molto più complicato di quanto dovrebbe essere, ma immagino che i programmatori pensino spesso questo quando osservano il codice che non hanno semplicemente scritto.
Spero di trovare motivi per cui il suo sistema è buono o cattivo. (Ho chiesto al professore e ha detto che avrei visto più tardi perché è meglio, il che non mi soddisfa.)
In sostanza, per evitare qualsiasi accoppiamento tra i suoi oggetti persistibili, i modelli (business logic) e le viste, tutto è fatto con le stringhe. Gli oggetti persistibili che vengono archiviati nel database sono hashtable di stringhe e i modelli e le viste si "sottoscrivono" tra loro, fornendo chiavi di stringa per gli "eventi" ai quali si iscrivono.
Quando viene attivato un evento, la vista o il modello invia una stringa a tutti i suoi abbonati che decidono cosa fare per quell'evento. Ad esempio, in una delle viste, i metodi del listener di azioni (credo che questo semplicemente imposta il BicycleMakeField sull'oggetto persistibile):
else if(evt.getSource() == bicycleMakeField)
{
myRegistry.updateSubscribers("BicycleMake", bicycleMakeField.getText());
}
La chiamata alla fine arriva a questo metodo nel modello Vehicle:
public void stateChangeRequest(String key, Object value) {
... bunch of else ifs ...
else
if (key.equals("BicycleMake") == true)
{
... do stuff ...
Il professore dice che questo modo di fare le cose è più estensibile e mantenibile rispetto a quando la vista chiama semplicemente un metodo su un oggetto di business logic. Dice che non esiste alcun accoppiamento tra viste e modelli perché non conoscono l'esistenza degli altri.
Penso che questo sia un tipo peggiore di accoppiamento, perché la vista e il modello devono usare le stesse stringhe per funzionare. Se rimuovi una vista o un modello o esegui un errore di battitura in una stringa, non ricevi errori di compilazione. Rende anche il codice molto più lungo di quanto penso debba essere.
Voglio discuterne con lui, ma usa la sua esperienza nel settore per contrastare qualsiasi argomento che io, lo studente inesperto, potrei fare. C'è qualche vantaggio nel suo approccio che mi manca?
Per chiarire, voglio confrontare l'approccio di cui sopra, con la visione ovviamente accoppiata al modello. Ad esempio, puoi passare l'oggetto del modello del veicolo alla vista, e quindi cambiare la "marca" del veicolo, fai questo:
vehicle.make = bicycleMakeField.getText();
Questo ridurrebbe le 15 linee di codice attualmente utilizzate SOLO per impostare la marca del veicolo in un posto, in una singola riga di codice leggibile. (E poiché questo tipo di operazione viene eseguita centinaia di volte in tutta l'app, penso che sarebbe una grande vittoria per la leggibilità e la sicurezza.)
Aggiorna
Il mio team leader e io abbiamo ristrutturato il framework nel modo in cui lo volevamo fare usando la tipizzazione statica, informato il professore e alla fine gli abbiamo dato una demo. È abbastanza generoso da permetterci di usare il nostro framework purché non gli chiediamo aiuto, e se possiamo mantenere il resto del nostro team in velocità - cosa che ci sembra giusta.