Hai bisogno di aiuto per capire alcuni OOP e concetti relativi alla programmazione [chiuso]

Delegati in C #: pensa a un delegato come a una classe, ma un'istanza di quella classe sarebbe un metodo piuttosto che un oggetto. Il delegato è definito dalla firma del metodo che verrà assegnato ad esso. La variabile di istanza può essere chiamata come se fosse il metodo stesso.

Dato questo esempio:

public delegate string StringWrapperDelegate(string input);

public string WrapInSquareBrackets(string input)
{
    return string.Format("[{0}]", input);
}

public string WrapInChevrons(string input)
{
    return string.Format("<{0}>", input);
}

public void DisplayWrappedString(StringWrapperDelegate wrapper, string input)
{
    Console.WriteLine(wrapper(input));
}

Ora puoi chiamare DisplayWrappedString , passando uno dei metodi WrapInXxx come argomento, ad esempio:

DisplayWrappedString(WrapInChevrons, "test");

Astrazione: Questa è una cosa concettuale che significa "tutto ciò che nasconde i dettagli di implementazione dal codice chiamante". Un delegato ne è un buon esempio, come visto sopra. DisplayWrappedString non sa nulla dell'implementazione del metodo wrapper che sta chiamando.

Architettura a tre livelli: qui c'è un confine fisico o nozionale tra il livello di presentazione (rigorosamente la logica dell'interfaccia utente, che dovrebbe essere minima), il livello aziendale (tutte le regole e la logica aziendale) e il livello dati (codice di accesso ai dati, anche minimo).

Il livello di presentazione generalmente comunica le richieste degli utenti al livello aziendale, che a sua volta accede al livello dati se necessario. La parte importante di questo, concettualmente, è che il livello di presentazione non dovrebbe parlare direttamente al livello dati.

I delegati sono semplicemente delle funzioni come oggetti. Puoi crearli, passarli in giro e poi chiamarli quando vuoi. Ad esempio, potresti convertire un delegato in una classe polimorfica con un metodo, ad esempio.

public delegate int SomeFunc(int);
public int Square(int i) {
    return i * i;
}
public int Double(int i) {
    return i * 2;
}
public int Func(int x) {
    SomeFunc f = null;
    if (someCondition) {
        f = Square;
    } else {
        f = Double;
    }
    return f(x);
}

Questo potrebbe essere banalmente convertito in

public interface SomeFunc {
    int DoWork(int);
}
public int Square(int i) {
    return i * i;
}
public class SomeFuncSquare : SomeFunc {
    int DoWork(int) { return Square(int); }
}
public int Double(int i) {
    return i * 2;
}
public class SomeFuncDouble : SomeFunc {
    int DoWork(int) { return Double(int); }
}
public int Func(int x) {
    SomeFunc f = null;
    if (someCondition) {
        f = new SomeFuncSquare();
    } else {
        f = new SomeFuncDouble();
    }
    return f.DoWork(x);
}

Naturalmente, a livello di macchina, potrebbero sembrare molto diversi, a seconda di cosa stai facendo. Ma potrebbero non farlo.

L'astrazione è il principio del nascondimento. Fondamentalmente, un'astrazione nasconde tutto tranne quello di cui hai bisogno. Un semplice esempio reale è una presa a muro. Prende qualsiasi dispositivo elettrico che si inserisce nel foro. La chiave qui è "qualsiasi" che ti permette di creare il tuo dispositivo e collegarlo senza dover costruire nuovi socket e così via. Lo stesso identico principio si applica nell'informatica: vuoi creare qualcosa che possa fare il più possibile con il minor numero possibile di modifiche, e il modo in cui lo fai è che definisci solo ciò che realmente bisogno. veramente hai bisogno di prendere un List<T> quando lo annulli solo su di esso? No, IEnumerable<T> sarebbe una scelta migliore, perché hai solo bisogno di enumerare su di esso, e in realtà, puoi prendere qualsiasi cosa che possa essere enumerata. La cosa importante qui è il "nulla", nel senso che puoi cambiarlo più tardi se lo desideri e non devi riscriverlo. Questo ti farà risparmiare tempo quando passerai a qualcos'altro, come una lista o una coda o altro.

Qualsiasi funzione generica è un esempio, perché in realtà non dipendono dai tipi su cui operano. Quando scrivi un contenitore, in genere non è necessario conoscere il tipo contenuto. Quindi l'unico contenitore astratto può contenere qualsiasi cosa.

Architettura a tre livelli? Non ne ho idea.

Per me ho finalmente capito i delegati quando li ho pensati come un'interfaccia per una funzione (Essere come una persona VB). O, più in generale, un'interfaccia di metodo. Ovviamente prima dovevo capire il significato di cosa sia un'interfaccia. E per capire il concetto di interfaccia ho dovuto capire cos'è una classe.

Quindi, quando tutta questa conoscenza è stata condensata in saggezza, i delegati hanno avuto molto senso e gli eventi sono diventati comprensibili nel quadro generale. Quando è successo, ho scoperto perché l'astrazione aveva senso e poi ho capito perché l'architettura N-Tier (con 3 che fosse una delle N possibili) era così attraente su qualcosa di diverso dalle applicazioni banali.

Sono domande come queste che mi costringono ad apprezzare non solo quanto so ma quanto non lo so.

Quindi ... La tua domanda è, beh, molto ampia e non so se qualcuno potrebbe davvero rispondere alla tua domanda senza conoscere il tuo livello effettivo di conoscenza e la saggezza che hai ottenuto da quella conoscenza (cioè quanta esperienza hai con la conoscenza).

MA il semplice fatto che chiedi dell'astrazione mi porta a credere, anche se potrei sbagliarmi, che non saresti in grado di comprendere veramente nessuna risposta data perché l'astrazione è il cuore e l'anima della programmazione dei computer per fare cose che gli umani apprezzano.