Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 20
  1. #1
    Utente di HTML.it
    Registrato dal
    Oct 2011
    Messaggi
    347

    [Java]passare da riga di comando a gui

    allora, il problema è: ho un programma intero(non sviluppato da me) che si usa da riga di comando, questo, ogni volta che fa una particolare azione, lo "comunica" con una System.out.print(); siccome ho pensato di creare una semplice gui per l'utilizzo e vorrei un consiglio per quanto riguarda quello che il programma comunica, cioè: devo per forza andare a modificare il codice del programma oppure c'è qualche altro modo più elegante?
    p.s. nella gui ovviamente ho predisposto una JTextArea che simulerebbe la console della riga di comando, dove appunto dovrebbero essere presentati i messaggi scritti dal programma

  2. #2
    Utente di HTML.it
    Registrato dal
    Oct 2011
    Messaggi
    347
    up

  3. #3
    dipende molto dal programma...se è stato fatto con tutti gli attributi al posto giusto, la parte di elaborazione dovrebbe essere separata da quella di visualizzazione, quindi dovresti solo creare le interfacce grafiche.

    Dubitando di ciò, credo che tu debba mettere mano al codice per forza

  4. #4
    Utente di HTML.it
    Registrato dal
    Oct 2011
    Messaggi
    347
    no, come ho detto è stato fatto per essere utilizzato da riga di comando, infatti guardando il codice, le chiamate a System.out.print vengono fatte non appena un'azione viene eseguita...
    In ogni caso, mettendo mano al codice, come faccio a fare in modo che le classi oggetto del programma comunichino con i componenti della mia interfaccia senza stravolgere il codice delle classi originali?
    L'interfaccia l'ho gia creata, l'unico problema è la comunicazione tra questa e il programma a parte...

  5. #5
    guarda, la cosa è un pò complessa non conoscendo di cosa si parla.

    In linea generale ti dico che ti conviene separare la visualizzazione dall'elaborazione, in pratica il pattern MVC!!!

    se ora la tua elaborazione è separata, puoi creare un layer intermedio che si occupi della comunicazione tra le classi di elaborazione e le classi di visualizzazione, che catturi i dati dagli uni e li passi agli altri.

    se riesci a creare questo layer, il gioco è fatto.

    ovviamente l'mvc prevede proprio questo, ma andrebbe fatto in fase di progettazione/realizzazione del software, non come nel tuo caso, che capisco sia particolare.

  6. #6
    Utente di HTML.it
    Registrato dal
    Oct 2011
    Messaggi
    347
    e ma un pattern mvc è un po complesso da realizzare a quanto so XD almeno per le mie conoscenze... per essere chiari è da poco che mi sono affacciato al mondo della programmazione

  7. #7
    consiglio spassionato: se è da poco che ti sei affacciato ma vuoi rimanerci...impara quei 3-4 pattern che sono fondamentali.

    l'MVC è uno di questo.

    e ti posso assicurare che è tra i meno complessi tra i pattern della "GO4" e altri pattern in generale.


    in due parole:

    devi strutturare la classe come se fossero 3 scatoloni, il primo scatolone contiene tutti i modelli, il secondo scatolone contiene tutti i controllori, e il 3 scatolone contiene tutte le visualizzazioni.
    i 3 scatoloni non conoscono gli elementi contenuti dagli altri, ma comunicano tra di loro, o per meglio dire, il model comunica con il controller e il controller comunica con il viewer.

    ognuno sà fare solo le sue cose e non gli interessa come gli altri facciano le loro.


    se entri in questa mentalità, vedrai che ti risolvera tanti grattacapi in futuro.

    Ovviamente questa è una mostruosa semplificazione del pattern (spero che nessun accademico legga quello che ho scritto X_X), ma per farti capire che è la strada migliore da intrapendere quando si lavora con le interfaccie grafiche...e non solo in java ovviamente

  8. #8
    Utente di HTML.it
    Registrato dal
    Oct 2011
    Messaggi
    347
    grazie mille per la pazienza XD e anche per la semplificazione, cercherò qualcosa su questi pattern, per studiarmi almeno l'MVC.

  9. #9
    Utente bannato
    Registrato dal
    Apr 2012
    Messaggi
    510
    Non è difficile da spiegare, l' applicazione che scrivi si divide nelle parti in cui gestisci i dati, nelle parti in cui visualizzi i dati, e nella parte che in genere scrive il programmatore, che è quella che gestisce il tutto.
    Ad esempio un modello può essere la classe ArrayList, una vista può essere la classe TextField, il controllore è la classe che scrivi te che gestisce il tutto.
    Se programmavi in C sarebbe stato facile sostituire don #define tutte le printf con una funzione che stampava i dati su una finestra in maniera più elegante.
    Ma anche in java puoi sfruttare gli strumenti che ci sono, e ad esempio con la funzione refractor di Eclipse, puoi sostituire tutti i System.out.println con il nome di un metodo e una classe che definisci te e che ha lo scopo di gestire tutti i dati e di visualizzarli correttamente.Questa sarebbe una classe controller.

  10. #10
    Utente di HTML.it L'avatar di Dark867
    Registrato dal
    Mar 2010
    Messaggi
    435
    Se l'applicazione è semplice evita il mvc come la peste, altrimenti usalo.
    Se l'app è semplice avresti 2 metodi:
    1) devi trovare tutte le parti in cui viene usato il System.out e cercare di sostituirle con metodi, ad esempio se in un metodo hai un output a video di un array tu a quel metodo fai ritornare l'array.
    Una volta compiuto questo refactoring devi creare una classe che si occupa del displaying grafico
    2)Crei una classe statica con un metodo output() che visualizza la stringa che gli viene passata su una textbox (esempio), poi sostituisci tutte le chiamate a System.out col metodo output()...è una cosa da fare solo quando l'applicazione è molto molto semplice perché complicheresti un bel po' le cose e inoltre è cattiva pratica.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.