Force Derived Class per implementare il metodo statico C #

Naviga le tue risposte
1

Quindi la situazione è come, ho poche classi, tutte con metodi CRUD standard ma statici. Voglio creare una classe base che sarà ereditata in modo che possa forzare l'implementazione di questi metodi CRUD. Ma il problema è che i metodi CRUD sono statici. Quindi non sono in grado di creare metodi virtuali con static (per ovvi motivi). È comunque possibile implementarlo senza compromettere la staticità.

Inoltre, la firma di questi metodi CRUD è simile.

es. ClassA avrà metodi CRUD con questo tipo di firme

  1. Elenco statico pubblico < ClasseA > Get ()
  2. public ClassA Get (int ID)
  3. public static bool Insert (ClassA objA)
  4. public bool di aggiornamento (int ID)
  5. public static bool Elimina (int ID)

ClassB avrà firme CRUD come

  1. Elenco statico pubblico < ClasseB > Get ()
  2. public ClassB Get (int ID)
  3. public bool statico Inserisci (ClassB objB)
  4. public bool di aggiornamento (int ID)
  5. public static bool Elimina (int ID)

Quindi voglio creare una classe base con una firma simile esatta, in modo che i metodi derivati ereditati implementino la loro versione.

Per E.g. BaseClass avrà metodi CRUD come

  1. elenco statico virtuale pubblico < BaseClass > Get ()
  2. public base statica virtuale BaseClassGet (int ID)
  3. public bool statico virtuale Insert (BaseClass objBase)
  4. public bool statico virtuale Aggiornamento (int ID)
  5. public statico bool virtuale Elimina (int ID)

Ma il problema è che non posso usare virtuale e statico a causa della sua logica ovvia che fallirà e non avrà alcun significato.

Quindi c'è una via d'uscita?

Inoltre, ho poche variabili comuni (costanti) che voglio dichiarare in quella classe base in modo da non doverle dichiarare su ogni classe derivata. Ecco perché non posso andare anche con l'interfaccia.

Tutto ciò che può essere fatto con la classe Abstract?

    
posta Krishnandu Sarkar 17.11.2014 - 07:34
fonte

4 risposte

17

Tali metodi non dovrebbero essere static (cosa succede se hai a che fare con due database?) e anche questi non dovrebbero essere nelle tue classi di entità.

Invece, dovresti avere un tipo separato, che rappresenta la memoria per questa entità. Quel tipo potrebbe essere generico, quindi il codice che non è specifico per l'entità non deve essere ripetuto.

In questo modo, l'ereditarietà funziona (l'archiviazione per ClassA può ereditare da qualche archivio di base) e non devi eseguire l'assurdo "Devo creare una persona per ottenere un elenco di tutte le persone".

Questo modello è ad esempio utilizzato da Entity Framework, lì il tipo di archiviazione è chiamato DbSet<T> .

    
risposta data 17.11.2014 - 23:49
fonte
3

Stai andando in questo modo nel modo sbagliato. Ogni volta che vuoi avere una serie di metodi correlati come questo e sembra che dovrebbero essere statici, considera la possibilità che tutto ciò significhi che stai cercando di metterli nel posto sbagliato. In questo caso, sembra che tu stia lavorando per il modello gateway dati tabella . Basta spostare quei metodi in una classe separata come metodi virtuali, avere una singola istanza condivisa di ciascuna di tali classi e una superclasse generica astratta per garantire che le implementazioni siano coerenti.

    
risposta data 18.11.2014 - 10:33
fonte
1

Con i metodi statici, non otterrai polimorfismo o alcun tipo di spedizione di classe base per questi metodi. Quindi, penso che tu stia cercando la "cosa sbagliata". Ma non lasciarti abbattere!

Se vuoi semplicemente far rispettare il fatto che questi metodi sono creati su tutte le classi derivanti da una base, o un'interfaccia, posso pensare a due semplici modi in cima alla mia testa.

Innanzitutto, nel progetto di test dell'unità, crea un test che utilizza la riflessione sull'assieme e non riesce se trova le classi derivate dalla tua base che non forniscono le implementazioni statiche delle tue routine crude.

In secondo luogo, crea un modello T4 che costruisca una classe di posta indesiderata per ogni classe derivata dalla tua base. Nella classe junk, inserisci chiamate fittizie su ciascun metodo crud. Quando si compila, il compilatore soffocherà su quei metodi statici mancanti.

Una soluzione non tecnica potrebbe colpire tutti gli sviluppatori che effettuano il check-in in classi con metodi statici mancanti con un martelletto gigante durante la revisione del codice.

    
risposta data 18.11.2014 - 04:37
fonte
1

Un altro modo di gestire questo è che la classe base prende una dipendenza da qualcosa del tipo: 

public abstract class MyBaseClass<T> : where T : object {
    protected IMyDataRepository _repository;

    public MyBaseClass(IMyDataRepository repository){
       _repository = repository;
    }

    public abstract bool TryInsert(T item);
    // so you can implement explicit persistence on the derived classes

}

È quindi possibile utilizzare il repository per gestire le modifiche di stato e persistenza durante il disaccoppiamento statico dalla classe. È possibile ottenere un grado di separazione rispetto all'eredità direttamente da DbSet<T> se il programma lo richiede.

Vedi: link

    
risposta data 26.11.2018 - 14:07
fonte

Leggi altre domande sui tag

I vantaggi di un team leaderless in Scrum Quando si chiama un numero intero casuale compreso tra 1 e 6, come posso far sì che a poco a poco sia meno probabile scegliere un numero più grande è? [duplicare]