Dovrei inserire l'interfaccia utente e la logica in classi separate?

6

Attualmente lavoro su un progetto per hobby che uso per saperne di più sulla programmazione e la programmazione Android / Java in generale. Recentemente, ho deciso di integrare jUnit nel progetto. Il solo fatto di averlo inserito non era un grosso problema, ma in realtà lo stava usando. Ho letto che un test unitario dovrebbe essere la definizione di ciò che un metodo (o componente) dovrebbe fare, e che i test di unità ti costringono a scrivere codice buono, o almeno migliore.

Ma i problemi iniziarono a verificarsi nel momento in cui scrissi il primo test unitario per testare qualche logica. Il metodo che volevo testare è solo un lavoro logico, nulla con l'interfaccia utente è stato fatto e i risultati vengono semplicemente salvati in variabili per un uso successivo. Ma, nella stessa classe, ho un metodo per visualizzare qualsiasi cosa abbia funzionato il primo metodo. E a JUnit non sembra piacere; per il secondo metodo ho bisogno (ovviamente) di importare UI, e jUnit lamenta che non conosce alcuna "classe Context Android". Fino ad ora, ho pensato che mettere le parti logiche e dell'interfaccia utente di un componente in una classe, ma i metodi separati sarebbe facilmente comprensibile e una pratica accettabile. Ma ora, perché "jUnit ti costringe a scrivere un buon codice", ne sono molto meno sicuro.

Quindi, dovrei inserire l'interfaccia utente e le parti logiche per un componente in classi separate? Esse dipendono l'una dall'altra, il metodo UI ha bisogno dei valori del metodo logico, ma il metodo logico non può fare nulla con i suoi valori calcolati senza il metodo UI. Ma perché qualcun altro potrebbe pensarla diversamente ... E quel "qualcun altro" è quello che probabilmente dovrà capire il mio codice dopotutto.

    
posta Namnodorel 26.11.2016 - 23:26
fonte

4 risposte

5

Modelli di progettazione dell'interfaccia utente come Model-View-Controller , < a href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter"> Model-View-Presenter e Model-View-ViewModel forniscono regolarmente meccanismi (cioè classi separate) che consentono Separazione di dubbi tra la superficie dell'interfaccia utente e la classe che lo gestisce, per gli stessi motivi che hai già citato.

    
risposta data 27.11.2016 - 00:01
fonte
5

Se questo è un progetto per hobby hai una meravigliosa opportunità di imparare qui.

Ti incoraggio a mantenere il tuo design così com'è. Non spostare la logica dall'interfaccia utente. Non separare affatto.

Avvia invece un altro progetto che fa la stessa cosa. Questa volta separa l'interfaccia utente e la logica. Mantenere il comportamento di entrambi i progetti lo stesso.

Noterai che il design separato ha molto più lavoro per lo stesso comportamento. Questo è sempre vero. Quindi potresti pensare che questo affare di separazione sia la vita del tuo tempo. Se la storia finisce qui, lo è.

Quindi progetta un'intera nuova GUI. Forse in un IDE diverso. Forse fare una versione basata su testo. Ora, dei due progetti, in cui è più facile apportare queste modifiche?

Il punto di risolvere problemi con il software piuttosto che con l'hardware è che il software è più facile da cambiare. Non scrivere il tuo codice in uno stile che mi fa pensare che avrei potuto assumere un ingegnere elettrico per risolverlo.

I don't know if it would be a good idea to rewrite the whole thing instead of seperating the classes... I've worked on this project for about halve a year now, so it would be either a lot of copy + pasting from the old project, or a whoooooollleee lot of work. – Namnodorel

Se il progetto è così grande potrebbe essere più intelligente scrivere un piccolo progetto esplorativo. Prendi una funzione più piccola, ad esempio una singola schermata del tuo progetto di hobby o una che alla fine farà parte di essa e creane una versione separata. In questo modo non devi aspettare l'intera conversione per ottenere un feedback per dirti se ti piace l'idea. Tieni presente che non sarà facile. Codirai contro ciò a cui sei abituato. Probabilmente ci vorrà del tempo solo per abituarsi a leggere questo tipo di codice.

MVC è una buona cosa da studiare ma non ti darà un piano chiaro dato che è davvero solo circa la separazione 3 non riguarda come queste preoccupazioni si parlano tra loro. Inoltre, fai attenzione alle tue ipotesi. La separazione non è solo in tre classi. Puoi scrivere classi che gestiscono ciascuna piccola parte delle tre preoccupazioni.

Guarda il schema di osservazione per vedere il modo in cui gli eventi dialogano tra loro. Il pattern Observer mi ha insegnato di più su programmazione guidata dagli eventi di qualsiasi altra cosa.

Esamina architettura a più livelli per vedere come separare più classi in livelli di preoccupazioni. Anche buone lezioni su queste righe in porte e adattatori e architettura pulita .

C'è molto da imparare qui e molti posti in cui cadere e arrendersi. Non fermarti solo perché è difficile. Ma non usarlo solo sulla fede. Fai in modo che ciascuna idea dimostri che ne vale la pena.

    
risposta data 27.11.2016 - 02:51
fonte
2

TL; DR

Sì, dovresti.

  • Una classe dovrebbe avere solo una ragione per cambiare.
  • Se la logica deve essere regolata, la tua classe ha un motivo per cambiare
  • Se l'interfaccia utente ha bisogno di essere cambiata, la tua classe ha un altro motivo per cambiare
  • Quindi la tua classe ha due motivi per cambiare
  • Questo è indesiderabile per molti motivi .
  • Si chiama principio di responsabilità singola.
  • Uno dei problemi di non seguire l'SRP è che la logica di business è più difficile da testare (cosa ti sta aspettando).
  • Un altro svantaggio di avere logica dell'interfaccia utente e logica aziendale nella stessa classe è che dovrai testare cose che non sono cambiate (o che pensi non siano cambiate). Quando modifichi la classe per cambiare il colore dell'interfaccia utente, ora devi testare di nuovo la classe in caso di rottura di qualcosa (il software è così). Se avessi separato UI e BL, non avresti bisogno di testare il BL. La tua classe logica aziendale non è stata modificata.

Detto questo, se questo è un progetto per hobby non dovresti preoccuparti troppo della manutenibilità e della testabilità, ma il fatto che tu stia mettendo jUnit nel coctail dice che vuoi saperne di più e fare le cose meglio che solo un semplice passatempo. Quindi inizia ad applicare i principi che rendono il software più gestibile e verificabile. jUnit è uno strumento professionale e come tale richiede alcuni standard.

    
risposta data 27.11.2016 - 00:17
fonte
-4

È possibile utilizzare un'architettura server / client per separare la logica (server) e l'interfaccia utente (client).

Vedi questo strumento: link

    
risposta data 30.10.2017 - 13:31
fonte

Leggi altre domande sui tag