Logica gestione magazzino

[Sevenis]

Ciao,
sto creando un gestionale per la gestione del magazzino: tre categorie di utenti (dipendente, magazziniere, boss), il dipendente può richiedere materiale, il magazziniere può gestire i prodotti e il boss visualizza i vari report. Sto cercando di analizzare come fare e mi chiedevo: ho creato una classe GestioneProdotto e all'interno ho messo un metodo inserisciProdotto() tramite il quale, ricevuto come argomento un Prodotto prodotto, lo inserisce nel db listaprodotti.

La mia idea è che, una volta loggato come magazziniere, si apra una finestra con dei bottoni tra cui "Inserisci prodotto". Una volta cliccato mi esce la finestra per l'inserimento che va a sfruttare GestioneProdotto.inserisciProdotto().

La domanda è: la finestra grafica di inserimento prodotto conviene inserirla nella classe che mi elabora l'interfaccia grafica del magazziniere oppure la inserisco direttamente nel metodo inserisciProdotto()?
Spero di essermi spiegato... grazie!

[andbin]

La domanda è: la finestra grafica di inserimento prodotto conviene inserirla nella classe che mi elabora l'interfaccia grafica del magazziniere oppure la inserisco direttamente nel metodo inserisciProdotto()?

Se inserisciProdotto ha a che fare con il DB ... allora non dovrebbe avere nulla a che fare con la interfaccia utente. Quindi no, non in inserisciProdotto.
Anche se la tua applicazione non fosse davvero "grande" (nel senso di molto estesa), cerca comunque di tenere sempre ben separati i concetti. Qui entrano in gioco i buoni principi della programmazione ad oggetti: incapsulamento, alta coesione, "DRY" (Don't Repeat Yourself) e altro, più l'eventuale uso dei design pattern.

[Sevenis]

Se inserisciProdotto ha a che fare con il DB ... allora non dovrebbe avere nulla a che fare con la interfaccia utente. Quindi no, non in inserisciProdotto.
Anche se la tua applicazione non fosse davvero "grande" (nel senso di molto estesa), cerca comunque di tenere sempre ben separati i concetti. Qui entrano in gioco i buoni principi della programmazione ad oggetti: incapsulamento, alta coesione, "DRY" (Don't Repeat Yourself) e altro, più l'eventuale uso dei design pattern.

Quindi dovrei fare:
-Classe prodotto con costruttore prodotto
-Classe con inserimento nel db
-Classe con la GUI inserimento prodotto
-Classe con la GUI generale dell'interfaccia magazziniere che ha i vari bottoni tra cui quello che apre la finestra "inserisci prodotto"

Giusto?

E per modificare o eliminare prodotto due classi a parte oppure metto tutto nella classe di connessione al db e poi cambio solo la classe con la GUI?

[Sevenis]

Allora, al momento le classi che ho progettato sono:
- Utente (costruttore utente + metodi get() & set())
- Prodotto (costruttore prodotto + metodi get() & set())
- SignUp (classe che tramite gui prende i valori da inserire in Utente utente e che passa al metodo interno Connetti(Utente) con il quale i dati vengono inseriti nel db)
- Login (classe che tramite gui prende email & password e ne controlla l'esistenza su db)
- ProdottoInserisci (classe che tramite gui prende i valori da inserire in Prodotto prodotto e che passa al metodo interno Connetti(prodotto) con il quale i dati vengono inseriti nel db)

Pensavo poi di creare delle finestre diverse in base a che sia capo, dipendente o magazziniere contenente pulsanti che, in base a quello che devono fare, richiama i vari metodi con relativa gui integrata (pop up di nuova finestra).

E' sbagliato come approccio?

[andbin]

Potresti (dovresti perlomeno) cercare di applicare il pattern "DAO". Trovi svariata documentazione online a riguardo. In sostanza definisci innanzitutto una interfaccia che descrive i metodi essenziali che sono sensati ed utili per una certa tipologia di dato.

Ad esempio per un Prodotto:

public interface ProdottoDao {
    List<Prodotto> leggiProdotti();
    // ... puoi aggiungere altri metodi per ricerche specifiche ....
    Prodotto leggiProdottoPerId(Long id);
    void inserisciProdotto(Prodotto prodotto);
    void aggiornaProdotto(Prodotto prodotto);
    void eliminaProdotto(Prodotto prodotto);
}

Poi se hai un DB es. MySQL puoi creare una implementazione (classe) concreta es. MysqlProdottoDaoImpl che implementa concretamente quei metodi.

Se si fa in modo che le implementazioni concrete dei Dao vengano assegnate dove necessario (in altre classi) magari attraverso un meccanismo di injection o magari estratte da una entità condivisa, è anche possibile arrivare ad una applicazione che è completamente "switchabile" come DB (es. da MySQL a Oracle a PostgreSQL) senza cambiare NULLA del resto della applicazione, magari solo cambiando un parametro di configurazione.

Un altro aspetto rilevante è quelle delle eccezioni. Se usi direttamente la API JDBC, essa tratta e lancia fuori solo eccezioni "checked". Generalmente in questo contesto si tende a "lanciar fuori" dai Dao delle eccezioni "unchecked" perché la dichiarazione e la considerazione obbligatoria delle eccezioni checked può spesso diventare un po' noiosa/onerosa.
Quindi sarebbe anche utile definire delle eccezioni unchecked (almeno una generalizzata) che "incapsulano" le eccezioni da JDBC.

C'è ancora un altro aspetto importante per evitare dubbie ripetizioni di codice. Immagina di avere svariate tipologie di dati: Prodotto, Utente, Cliente, ecc...
Se hai già usato JDBC, sai sicuramente cosa vuol dire fare una query per estrarre N record da una tabella e alla fine dare in uscita un List<XYZ> (dove XYZ uno dei tuoi dati). Ci sono infatti una serie di passi ben precisi da fare:

- ottenere una Connection
- create lo Statement
- eseguire la query
- ottenere il ResultSet
- creare una nuova lista parametrizzata <XYZ>
- iterare con il classico idioma while (rs.next()) { ...... }
- estrarre i dati dalle colonne per ciascun record
- creare e impostare un oggetto di tipo XYZ
- aggiungere l'oggetto nella lista

alla fine:
- chiudere in modo appropriato le risorse
- chiudere la Connection (o magari meglio "rilasciarla" in modo che sia ri-usabile ... dipende dal contesto).

Quali di queste operazioni sono standard di JDBC e quali specifiche per la certa tipologia di dato XYZ? Appunto. Se hai svariate tipologie di dati (da 3~4 in su) e NON stai usando framework/librerie di più alto livello rispetto a JDBC, dovresti anche pensare a realizzare un meccanismo di "template" in modo da separare i passi standard per JDBC da quelli specifici per quel tipo di dato.

Se puoi usare un framework/libreria al di sopra di JDBC, potrei consigliarti MyBatis che perlomeno semplifica moltissimo la "mappatura" tra JDBC e le tue classi di dati.

Per questo e per il resto c'è comunque molto da "studiare".

[Sevenis]

Molto, in effetti... ho capito molto poco di quel che hai detto ma vedo di studiare qualcosa in merito per approfondire questi aspetti!

[andbin]

Molto, in effetti... ho capito molto poco di quel che hai detto ma vedo di studiare qualcosa in merito per approfondire questi aspetti!

Anche senza considerare astrazioni con le interfacce, inizia perlomeno a fare una classe ProdottoDao con i metodi per le classiche operazioni CRUD (Create-Read-Update-Delete) che ti servono.