Функция, возвращающая список различных возможных классов детей

Question

У меня есть источник привязки, который может быть привязан к списку A или списку B. В зависимости от того, является ли это A или B, когда я нажимаю «Сохранить», я хочу вызвать сохранение метод соответствующего репозитория.

Я был в состоянии создать этот метод, чтобы проверить, если список загрязнен и нуждается в экономии:

private static bool IsDirty<T>(TList<T> list) where T : IEntity, new() 
{ 
    foreach (var entity in list) 
    { 
     if (entity.IsDirty) 
      return true; 
    } 
    return false; 
} 

Однако у меня возникли проблемы со следующим:

var list = CurrentTList<A>(); 

и

private TList<T> CurrentTList<T>() where T: IEntity, new() 
{ 
    switch (currentRatesTable) 
    { 
     case RatesTables.A: 
      return (TList<T>) _bindingSourceMaster.List; 
     case RatesTables.B: 
      return (TList<T>) _bindingSourceMaster.List; 
     default: 
      return null; 
    } 
} 

Это лучший способ получить мой текущий список из источника данных? Я хотел бы избежать с помощью переключателя, как это так, как это не выглядит прямо мне:

switch (currentRatesTable) 
{ 
    case Form1.RatesTables.A: 
     var list = CurrentTList<A>(); 
    case Form1.RatesTables.B: 
     var list = CurrentTList<B>(); 
    // ... 
} 

Answer 1

Да, как говорит Sayse, вы должны себе интерфейс и/или абстрактный класс. Если есть много общего кода, вы можете начать с последнего. Вот что-то нарисовало от старого тестового проекта. Он использует другой подход (каждый элемент в коллекции - это то, что актуально как «грязное», и есть иссеченные методы, которые будут искать коллекцию для них), но вы должны иметь возможность при необходимости адаптироваться:

[DataContract] 
public abstract class Dirty : Object 
{ 
    protected bool _isdirty; 
    public bool IsDirty 
    { 
     get { return _isdirty; } 
     set 
     { 
      _isdirty = value; 
     } 

} 

public abstract class DataStore<T> where T : Dirty 
{ 
    private string _path; 
    private string _tempFile; 

    protected DataStore(string path, string tempfile) 
    { 

     _path = path; 
     _tempFile = tempfile; 
    } 
} 

Итак, DataStore придерживался логики управления этими списками. Идея для меня заключалась в том, что оба класса, унаследованные от Dirty, сериализовались в JSON, поэтому, если у их членов были правильные атрибуты, все они были правильно сериализованы, и поэтому для каждого класса для каждого класса не было никакой логики. Таким образом, все, что они должны были сделать, чтобы создать их хранилище было:

[DataContract] 
    public class Account : Abstracts.Dirty 
    { 
     #region DataStore fields and singleton 
     private static volatile StoreClass _store = new StoreClass(); 
     protected static StoreClass Store 
     { 
      get 
      { 
       return _store; 
      } 
     } 
     /// <summary> 
     /// Store is the data store for the Account class. This holds the active list of Accounts in a singleton, and manages the push/pull to the JSON file storage. 
     /// </summary> 
     protected class StoreClass : Abstracts.DataStore<Account> 
     { 
      #region Singleton initialization and Constructor 

      public StoreClass() 
       : base("accounts.json", "TEMP_accounts.json") 
      { 

      } 
      #endregion 
     } 
    } 

Я вырезал несколько тысяч линий на этом проекте только от датастора, но это было довольно сумасшедшим. Основная идея состоит в том, чтобы построить нужную логику в классе DataStore, чтобы сохранить список, и нацелиться на то, как вы сохраняете/загружаете его с помощью того, как вы вызываете его конструктор из дочернего элемента StoreClass.