Accedi alle funzioni dal controllo utente senza eventi?

Question

Accedi alle funzioni dal controllo utente senza eventi?

#1 da (1 voti)
#2 da (0 voti)

-1

Su alcune funzioni generiche, sembra che l'accesso a una funzione su mainform direttamente dall'usercontrol sia più semplice che generare un evento. Ad esempio: una funzione sul modulo principale che visualizza un centro di controllo desiderato centrato e ottimizzato.

Rendere statica questa funzione, o accedere a questa funzione per riferimento dal controllo utente al suo genitore, piuttosto che innalzare un evento, sembra molto conveniente. In questo modo:

usercontrol_A uc_a = new usercontrol_A();
MainForm mainform_functions = (MainForm)Parent;
mainform_functions.DisplayControl(uc_a);

Aumentare un evento sembra più complesso in questi casi - Devo dichiarare tutti gli eventi di new userControl_B (che include anche l'avvio di usercontrol_C e la sua visualizzazione) all'interno dell'evento che mostra (e avvia) userControl_B:

  userControl_A.ShowUserControl_B+= (s,e) =>
 {
 usercontrol_B uc_b = new usercontrol_B();   DisplayControl(uc_b);
    uc_b.show_uc_c += (s2,e2) => {usercontrol_C uc_c = new usercontrol_C(); DisplayControl(uc_c); }
 }

troppa confusione qui .

È difficile da codificare e leggere in seguito. (In aggiunta, passare parametri ad un altro usercontrol è un incubo come questo - ho bisogno di salvare il parametro artificialmente sulla classe usercontrol del mittente e poi di lanciarlo più tardi all'interno dell'evento)

Qual è la tua opinione? È del tutto "proibito" codificare in questo modo, almeno su funzioni generiche come ho detto? Non è un codice più chiaro che ha bisogno di qualche piccolo ritocco per il riutilizzo preferibile?

design-patterns separation-of-concerns observer-pattern event user-control

posta BornToCode 31.10.2012 - 01:36

fonte

2 risposte

Leggi altre domande sui tag design-patterns separation-of-concerns observer-pattern event user-control

Qual è il vantaggio di avere il codice sorgente per ICS? Esistono validi modi per eliminare / ridurre lo stato?

score 1 · Answer 1

Questo è il motivo per cui esistono schemi creativi, spesso la creazione di tipi di volte può essere complicata come ti sei imbattuto.

Penso che tu voglia una fabbrica astratta qui ( avvertenza : non è vero se il controllo utente A / B / C ha attributi sostanzialmente identici, se sono identici hai solo bisogno di un singolo metodo che creerà un controllo con la configurazione desiderata che può essere trattato come controllo A, B o C

public interface IControlCreator
{
    Control CreateControl();
}

public class ControlFactory<T> where T : IControlCreator, new
{
    GetControl()
    {
        return (new T()).CreateControl();
    }
}

public ControlACreator : IControlCreator
{
    Control CreateControl()
    {
        Control controlA = new Control();
        DisplayControl(controlA);
        controlA.show_uc_b += (s,e) => new ControlFactory<ControlBCreator>().CreateControl();
    }
}

public ControlBCreator : IControlCreator
{
    Control CreateControl()
    {
        Control controlB = new Control();
        DisplayControl(controlB);
        controlB.show_uc_c += (s,e) => new ControlFactory<ControlCCreator>().CreateControl();
    }
}

Quindi ogni volta che vuoi un controllo, ci saranno gli eventi appropriati collegati dalla sua classe Creator, tutto ciò che devi chiamare per ottenere uno è nuovo ControlFactory<ControlWhateverCreator>().CreateControl();

Per favore, qualcuno mi faccia sapere se ho qualcosa di sbagliato qui; Non ho mai scritto una fabbrica astratta prima d'ora. È un sacco di spese generali, quindi tendo ad evitare i facotries, ma sembra l'approccio giusto in base all'ambito del problema descritto dall'OP.

score 0 · Answer 2

Potresti semplicemente indicare concettualmente cosa stai cercando di ottenere? La spiegazione e il codice limitati rendono difficile giudicare l'immagine più grande che sarà importante qui.

Tuttavia, per rispondere alla tua domanda iniziale più in generale:

On some generic functions, it seems that accessing a function on mainform directly from the usercontrol is easier than raising an event.

A seconda del tuo scenario:

Non è vietato se il tuo utente controlla sempre che si trovi all'interno di quel genitore specifico. In tal caso, passerei il genitore (o un'interfaccia che il genitore implementa) al costruttore del controllo utente (constructor injection). Ciò rende impossibile che il genitore sia diverso dal tipo atteso corretto.
Se è possibile riutilizzare quel controllo utente in genitori diversi, il casting con il genitore specifico lo renderebbe impossibile. Ecco dove gli eventi sarebbero tornati utili. Ciò consente un codice molto più abbinato.

Tuttavia, a giudicare dal tuo codice, direi che probabilmente gli eventi sono la strada da percorrere. Sembra che tu stia codificando un sacco di cose come userControl_A.ShowUserControl_B . Forse potresti gestirlo concettualmente con i tuoi genitori collegandoli insieme lì? Sto pensando di creare una classe di controllo utente astratta che abbia qualcosa lungo un evento Closed che la classe genitore gestisce dopo di che mostra il prossimo controllo utente.