Каков наилучший способ «наследовать» набор переменных и процедур, которые являются статическими, чтобы их можно было переопределить

Question

Я прочитал несколько хороших статей и т. Д. Здесь и от Google о попытках выполнить мою задачу.Я, вероятно, слишком усложняю вопросы.

Теперь, прежде чем вы все это скажете, Я знаю, что вы не можете наследовать статические элементы / процедуры .Я спрашиваю, как делать то, что мне нужно, и правильно.

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

Что мне нужно, чтобы сделать, это сделать базустатический класс, который будет просто работать и выполнять логику (The Helper), но тогда мне нужно иметь возможность создать новый класс (по существу, Static), который я могу добавить в один или несколько «новых» статических методов, которые переопределяют базовые методы, ногде этот класс теперь действует как базовый - проходя через своих членов.

Сначала я подумал об использовании интерфейса, но для этого нужен экземпляр.

Какой, по вашему мнению, лучший способ решить эту проблему?

Answer 1

Похоже, что один из ваших классов может быть обычным классом. Затем вы можете использовать композицию, чтобы соединить их вместе, чтобы достичь того, что вам нужно. Я бы разбил вещи так:

internal class TaskProcessor
{
    // All of the work/logic goes in this class which can have instances
}

public static class StaticHelper
{
    private TaskProcessor _processor = new TaskProcessor();

    public static void SomeMethod()
    {
        _processor.SomeMethod();
    }

    // And so on
}

Answer 2

Для меня это и есть цель методов расширения .Предоставление безопасного способа обмена функциональными возможностями между типами, которые соответствуют стандарту.Вы можете иметь один и тот же метод расширения, который будет перегружен, чтобы обеспечить различные функциональные возможности для типов disirit, сохраняя семантически похожий код.

Answer 3

Если вы пытаетесь избежать зависимости от System.Web везде, вы можете использовать своего рода внедрение зависимостей.

// Base assembly; does not reference System.Web
public class HelperBase
{
    public virtual void DoSomething() { ... }
    public virtual void DoSomethingElse() { ... }
}

public static class StaticHelper
{
    public static HelperBase Helper { get; set; }
    static void DoSomething()
    {
        Helper.DoSomething();
    }

    static void DoSomethingElse()
    {
        Helper.DoSomethingElse();
    }
}

// HelperWeb assembly; references System.Web, base assembly
public class HelperWeb : HelperBase
{
    // override base implementation, using System.Web
    public virtual void DoSomethingElse() { ... }
}


// usage at top level:

StaticHelper.Helper = new HelperBase();
// or
StaticHelper.Helper = new HelperWeb();

StaticHelper.DoSomething();

Таким образом, StaticHelper не должен ссылаться на System.Web. Вам нужно ссылаться на System.Web только на верхнем уровне, если вы на самом деле используете Helper, которому нужен System.Web. Вы даже можете использовать отражение для условной загрузки сборки HelperWeb только во время выполнения.

Answer 4

См. Этот ответ: Почему я не могу иметь абстрактные статические методы в C #? , чтобы понять, почему абстрактные статические классы нельзя использовать в c #

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

public class Singleton
{
   private static Singleton instance;

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null)
         {
            instance = new Singleton();
         }
         return instance;
      }
   }
}