Perché l'eredità dovrebbe essere evitata?

9

Ricordo di aver imparato VB4 e di aver trascinato un pulsante su un modulo, facendo doppio clic su quel pulsante e digitando il codice in quel gestore di eventi con cui ero appena stato magicamente benedetto. Venendo da QBASIC ero elettrizzato dalla "V" in "VB", il visual designer era letteralmente la cosa migliore dopo il pane a fette.

Ovviamente si poteva fare tutto programmaticamente ma la magia della "V" era così attraente che non si poteva fare a meno di trascinare quel pulsante. Siamo stati incoraggiati a seguire questa strada.

Ma poi alcuni anni fa ho iniziato a conoscere C # e il framework .net ed ero affascinato dal modo in cui tutto quello che pensavo di sapere fosse appena uscito dalla finestra. C'è un sacco di magic in corso in VB6 che è completamente svelato in .net: take constructors e il metodo InitializeComponents per esempio. In quest'ultimo troverai tutte le istanze di controllo che hai trascinato dalla casella degli strumenti, tutti gli eventi che hai registrato e le proprietà che hai impostato nella finestra di progettazione.

E va bene ... credo. È solo che, mi sembra di non "possedere" quello che sta succedendo, questo codice che posso modificare solo tramite il designer mi infastidisce. Ogni volta che copi un pulsante che dice "Ok" da un modulo a un altro (a volte insieme al suo fratello "Annulla"), stai effettivamente duplicando il codice, e questo è un peccato non è vero? ASCIUTTO, non ripeterti, dice il Papa .

Religioni e scuole di pensiero a parte, in tutta obiettività, non dovremmo invece ricavare forme dalle forme di base e avere il pulsante "Ok" (e tutti i suoi amici) in diretta sul modulo di base? Qualcosa come un FormBase da cui deriva un DialogFormBase ; tutte le classi create in pochissimo tempo ... digitando il codice. I pulsanti vengono creati in base a come viene instanciata la classe (ovvero un argomento enum costruttore determina quali pulsanti devono essere creati), i controlli sono disposti all'interno di una disposizione di pannelli divisi e pannelli di layout del flusso, iniettati nel modulo come Content che si inserisce nel pannello dei contenuti principale. Non è questo ciò che ASP.net fa con le pagine master e i segnaposto dei contenuti? Vorrei ricavare un modulo quando ho bisogno di una nuova "pagina master", ma questa nuova "pagina master" deriva ancora da una classe di modulo di base in modo che le immagini siano coerenti in tutta l'applicazione.

Per me è molto più riuso del codice di qualsiasi altra cosa che abbia mai fatto con il designer in WinForms, e non era nemmeno difficile, e il codice non è ingombro di 200 righe metodo su cui non ho controllo, posso inserire commenti dove mi piace, non verranno sovrascritti da un designer. Immagino sia solo una questione di schemi e architettura, che è quello che mi ha portato a questo link: Miglior design per i moduli di Windows che condivideranno funzionalità comuni , in cui mi sono reso conto che ero in grado di individuare, eccetto la risposta lì, suggerisce esattamente quello che sto facendo, ma si consiglia contro l'ereditarietà perché delle considerazioni del progettista. Questa è la parte che non ho . Preferirei consigliare contro usando il designer perché delle considerazioni sulla struttura del codice, specialmente per quanto riguarda la forma e l'ereditarietà del controllo, che non vedo alcun motivo per evitare altro che bene rompe il designer .

Non possiamo essere solo pigri, quindi quale parte mi manca?

    
posta Mathieu Guindon 23.03.2013 - 16:56
fonte

4 risposte

9

Mi opporrò a te con un paradigma diverso: favorisci la composizione sull'ereditarietà.

Anche quando inizi a scrivere codice GUI a mano e usi l'ereditarietà per condividere comportamenti e immagini tra i moduli, avrai lo stesso problema del normale design OOP. Diciamo che hai DialogForm, che ha pulsanti OK / Annulla e GridForm, che ha una griglia. Si derivano tutte le finestre di dialogo da DialogForm e tutti i moduli con Grid di GridForm. E poi scopri che vuoi la forma con entrambi. Come lo risolveresti? Se si utilizza l'ereditarietà della forma, non c'è modo di risolverlo. Dall'altro lato, se si utilizza UserControls, è sufficiente inserire GridControl nel modulo e utilizzarlo. E puoi ancora utilizzare il designer con UserControls, quindi non devi perdere tempo a scrivere noiosi codici GUI.

    
risposta data 23.03.2013 - 18:00
fonte
2

Gran parte di questo è legato allo stack tecnologico di scelta.

WinForms e WPF possono essere entrambi framework di interfacce utente .NET, ma variano notevolmente nel modo in cui si raggiunge l'obiettivo finale. Alcuni paradigmi si muovono tra le tecnologie, ma gli altri no e non dovresti provare a forzare un paradigma semplicemente perché ritieni che sia pensato per esistere in ogni struttura. C'è una ragione per cui MVVM è orientato su WPF / SL e MVC è un concetto separato in ASP.NET da WebForms e così via. Alcune tecnologie funzionano meglio con determinati paradigmi.

Tieni presente che il codice generato deve generalmente essere rimosso dalle tue preoccupazioni di DRY. Sebbene applicabile in alcuni casi, il più delle volte dovrebbe essere ignorato. I concetti di DRY dovrebbero certamente rimanere un focus al di fuori del tuo livello Presentation ma a livello di Presentation il codice generato è più spesso un sottoprodotto del framework in cui stai lavorando. Questo non vuol dire che non puoi applicare i principi di DRY nel tuo approccio ma rimanere prudenti. Potresti creare una base form ed ereditarla indefinitamente? Sì. Potresti trascinare e rilasciare componenti su un nuovo modulo ogni volta se necessario? Sì. Mantieni la concentrazione sull'obiettivo finale, evitando potenziali difetti, rendendo più semplice il refactoring a valle e la scalabilità mentre lavori all'interno dei confini dello stack tecnologico di scelta.

    
risposta data 23.03.2013 - 22:30
fonte
0

puoi utilizzare l'ereditarietà fornendoti incapsulare correttamente i tuoi campi e compilare di conseguenza. Se desideravi utilizzare l'ereditarietà, il mio suggerimento sarebbe di avere la forma base e un modello corrispondente per quella forma, e per ogni derivazione derivare sia la forma che il modello.

Un'alternativa molto migliore sarebbe raggruppare i controlli relativi in uno o più controlli UserControl. Hai solo bisogno di un po 'di logica per inserirvi i dati rilevanti.

    
risposta data 24.03.2013 - 23:42
fonte
0

Sono totalmente d'accordo con Mason Wheeler, anche se in tre anni forse anche lui stesso aveva cambiato idea.

Sto cercando delle alternative per migrare dagli eseguibili di Delphi sul WEB.

Fino ad ora mi sono deciso per UNIGUI, perché posso ancora usare l'ereditarietà della forma. Vorrei che Delphi avesse Mixin come Dart, in quanto mi avrebbe permesso di avere meno antenati di forma. Ma credo che le persone scrivano molto più codice in MVC che con Visual Form Inheritance, poiché la maggior parte della navigazione, chiamate alle regole di validazione nel datamodule (applyupdates), criteri di filtraggio sql, ricerca nel set di dati del client, tutto è scritto in 5 forse 6 Form antenati.

Anche con "Con MVC sarà più facile per te lasciare Delphi nella feature" per me non funziona come argomento, dal momento che le persone hanno invitato OOP, sono tutte classi, proprietà, metodi. Quindi tutto ciò di cui ho bisogno è un traduttore. Davvero non ho trovato alcun vantaggio, forse per siti web che sono molto meno complicati ma cambiano in base giornaliera.

    
risposta data 14.07.2016 - 18:27
fonte

Leggi altre domande sui tag