La tua domanda in combinazione con i tag utilizzati è un po 'ambigua. Non sono del tutto sicuro se parli di progettazione dell'interfaccia utente o di progettazione orientata agli oggetti. Pertanto, cercherò di fornire risposte a entrambi.
UI Design
Quando si tratta di progettazione dell'interfaccia utente, prima leggi e prova a capire le otto regole d'oro di interfaccia utente . Ci sono alcune varianti a questi là fuori, ma otterrai il succo. La prima regola dice che Cerca la coerenza . Con il design che hai descritto, fa proprio questo: i controlli Aggiungi e Aggiorna si assomigliano tra loro. Apparirà una schermata familiare e gli utenti non dovrebbero avere difficoltà a orientarsi su quella particolare forma.
Inoltre, quando hai a che fare con dati che possono essere visualizzati come una tabella, devi sempre fornire due viste:
- visualizzazione multi-record, come griglia di dati, in cui è possibile osservare più record contemporaneamente, possibilmente con un livello di dettagli inferiore
- visualizzazione record singola, che funge da visualizzazione dettagliata per un singolo record e può essere utilizzata per aggiungere o aggiornare record
La finestra di dialogo che hai descritto suona come se potesse essere utilizzata per quest'ultimo scopo.
Modifica: espansione della risposta basata sul primo commento di seguito
Dal punto di vista dell'interfaccia utente, suona bene per me. Inoltre, dal punto di vista della riusabilità. Hai già scritto del codice una volta. Per scrivere una nuova finestra di dialogo che sarebbe simile alla precedente molto solo per un'altra operazione, si otterrebbe un sacco di codice duplicato. Il codice duplicato è un terreno fertile per i bug che sono il risultato di aggiustare qualcosa in un posto, ma dimenticando di sistemarlo in un altro. Tienilo così. Il codice più comune è il migliore.
Design orientato agli oggetti
Spero davvero che la tua finestra di dialogo non faccia tutte e tre le cose che hai descritto. In realtà, spero che non faccia nessuno di quelli. Le operazioni CRUD non devono essere eseguite dai componenti dell'interfaccia utente. Le componenti dell'interfaccia utente dovrebbero solo occuparsi della rappresentazione visiva dei dati e della raccolta dei dati dagli utenti. Tutto il resto dovrebbe essere eseguito da altri componenti. Dalla progettazione che hai descritto, potresti facilmente implementare schema di comando . Dovresti semplicemente istanziare un comando appropriato basato sugli argomenti passati attraverso un costruttore della finestra di dialogo, e quindi lasciare che il comando esegua ciò che deve essere eseguito. La finestra di dialogo sarebbe solo un involucro attorno ad essa. Un bel corpo dell'auto, se lo si desidera, mentre tutto il lavoro sarebbe svolto dal motore sotto forma di una classe di comando appropriata.
Spero che questo aiuti.
Modifica: espansione della risposta basata sul primo commento di seguito
In realtà, questa API esterna funziona perfettamente con Pattern di comando . Tutto ciò che devi fare è racchiudere le chiamate a quell'API esterna in una singola classe e quindi richiamare le chiamate appropriate dalle diverse classi di comando, che verrebbero istanziate in base al tipo di finestra di dialogo.
Inoltre, consulta Iniezione di dipendenza . Ciò dovrebbe aiutarti a disaccoppiare il codice relativo all'interfaccia utente dal codice di gestione dei dati, che dovrebbe migliorare la leggibilità e la testabilità del codice.