Java: MVC e classe anonima per controller
Ho una domanda sul pattern MVC. Sto cercando di usarlo per il progetto desktop (cioè non per l'applicazione net), usando Java in IntelliJ IDEA. Sto cercando di creare Modello, Vista e Controller, secondo il modello MVC. La mia domanda è: è sicuro dire che dal punto di vista di Java, i metodi contrassegnati servono già come controller e in realtà non è necessario creare una classe di controller esplicita come classe separata? Come questo:
O devo devi creare una classe CalculatorController esplicita, come questa:
Ricorda che il mio compito è preservare il patter MVC, dove le attività per M, V e C sono chiaramente divise. Di queste 2 opzioni, quale conserva il pattern MVC? Solo il secondo, o entrambi allo stesso modo? Grazie!
1 answers
Seconda opzione
Se usi i tuoi controller come classi interne anonime, come testerai il tuo livello di controller? Se non si separano i controller, non sarà in grado di prendere in giro quindi a scopo di test.
Anche se non vuoi scrivere test, la prima opzione creerà un accoppiamento davvero difficile tra le Viste e il Controller. Non c'è alcuna separazione!
Preferisci creare esplicitamente i tuoi controller e creare interfacce per poi prima dell'implementazione. Renderà TDD molto più semplice e farai anche una migliore progettazione del codice nel tuo progetto.
Ma ricorda, è solo la mia opinione. Studia sempre per assicurarti che la tua decisione di progetto sia corretta e funzioni per te.
Date un'occhiata in questo articolo, ha una semplice implementazione del modello: https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm
Modifica
Confrontiamo entrambi approccio.
- Testabilità
Classi interne: non è possibile testare il livello di controllo. Tutti i tuoi controller sono classi interne anonime. Quindi non hai accesso a then, rendendo impossibile il test. Nell'architettura MCV è davvero importante testare i controller. Conclusione: davvero male per i test.
Classi esplicitamente : puoi prendere in giro la vista e il modello in modo da poter testare i controller. Stessa logica va quando testare la vista e il modello. Conclusione: Facile da testare.
- Manutenibilità
Classi interne: tutta la logica del controller è all'interno di classi interne anonime (o lambda). Fidati, non lo vuoi. Tutta la complessità della tua app sarà all'interno di una classe che non doveva diventare grande. Un semplice esempio:
//I need to get the people older than 50 years old, present to the user and wait for a click. If the list is empty, do something, if it's not do something else.
buttonRefresh.onClickListener(() -> {
List<Person> people = model.requestPeople();
people = people.stream()
.filter(p -> p.getAge > 50)
.collect(Collectors.toList())
[code to create an adapter]
if(people.isEmpty()){
[do something...]
} else{
[do something else...]
}
})
Questo è un codice molto semplice e sta già diventando confuso. Cosa succede se ho un altro lambda all'interno del mio se e altro?? Il più il tuo codice diventa più grande all'interno di classi interne anonime, peggio. Conclusione: questo è un male per la manutenibilità perché il tuo codice crescerà nel posto sbagliato.
Classi esplicitamente : il codice può crescere all'interno di una classe. È possibile aggiungere dipendenze lì, creare metodi, avere classi interne...
- Separazione delle responsabilità
Classi interne : non esiste un livello controller, per essere vero. Tutto il codice del controller è all'interno le tue classi di visualizzazione, quindi la Vista e il Controller e fondamentalmente le stesse classi. Di conseguenza, avrai una vista davvero enorme con un sacco di codice disordinato. Conclusione: Male, quasi tutto il codice della tua applicazione sarà nelle classi di visualizzazione.
Classi esplicitamente : il controller e la Vista hanno una separazione molto chiara. La tua vista avrà solo metodi per aggiornare la vista.
(so che stai per creare molti metodi con fondamentalmente 1-3 righe di codice nelle classi di visualizzazione. Ma è meglio di enormi metodi con logica di visualizzazione e controllo nello stesso posto.)
Questo è quello che penso. Ma puoi sempre provare entrambi gli approcci e confrontare i risultati!