Многократные вызовы внешнего статического метода ИЛИ вызывают один внутренний метод, который вызывает внешний статический метод

Question

Итак, мой вопрос:

Я получил статический класс со статическим методом с именем:

static class A() {
     public static MethodA() { }
}

, и я получил другой класс, который вызовет MethodA () статического классанесколько раз:

static class B() {
     public static MethodB1() {
         MethodA()
     }
     public static MethodB2() {
         MethodA()
     }
     public static MethodB3() {
         MethodA()
     }
     public static MethodB4() {
         MethodA()
     }
}

Является ли это правильным подходом или я должен сделать это следующим образом (вызвать внутреннюю функцию, которая является единственной ссылкой на статический метод):

static class C() {
     public static MethodC1() {
         StaticCaller()
     }
     public static MethodC2() {
         StaticCaller()
     }
     public static MethodC3() {
         StaticCaller()
     }
     public static StaticCaller() {
         MethodA()
     }
}

IВыяснилось, что это вопрос дизайна или философии, но есть ли какое-то техническое преимущество, например, поддерживаемый или масштабируемый код?

Редактировать: Или даже улучшения производительности?

Answer 1

Это считается основанным на мнении, поскольку оба метода имеют свои преимущества. Многие разработчики здесь, в SO, имеют свои собственные предпочтения, поэтому сложно ответить, не опровергнув мнения.
В классе B каждый вызов идет непосредственно в метод A, в то время как в классе C вызов сначала должен пройти через локальный метод, прежде чем он сможет это сделать. перейдите к методу А. Этот дополнительный шаг можно считать избыточным, и поэтому предпочтителен класс B.
Однако по любой причине вам, возможно, придется изменить вызов с метода A на метод D с класса, который вы не сделаливсе же. В этом случае вам придется изменить четыре метода в классе B и только один в классе C. Таким образом, класс C легче поддерживать и настраивать.
Таким образом, оба имеют свои плюсы и минусы, а класс B дает очень незначительный прирост производительности. ,(Буквально тиканье часов!)
Так что, в общем, это не имеет большого значения, поэтому я советую выбрать решение, которое лучше всего читать разработчикам. Это означает добавление комментариев, использование правильного форматирования, использование четких имен методов и попытка избежать повторения!
И этот последний комментарий означает, что и класс B, и класс C являются плохой практикой, поскольку каждый класс повторяет вызов некоторогометод . Вы должны пересмотреть форму этих методов в один метод. Что может быть сложно, так как в этих методах может быть много различий.

Answer 2

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

Я ненавижу работать со статикой. Замена вызова на один статический вызов другим является болью. По этой причине я предпочитаю C. Это легко заменить.

Но у меня действительно есть два других варианта, которые стоит рассмотреть:

1st

Поскольку я ненавижу статику, я стараюсь не писать их. И все ваши классы по-прежнему статичны, преодолевая проблему. Если мне нужно что-то подобное, и у него есть какое-то непостоянное поле, я бы не стал статичным. Вместо этого я бы сделал это обычным классом, требующим экземпляра. А затем создайте статическое поле, которое принимает экземпляр этого класса. Это может звучать не так, как различие, но замена:

static staticsProvider SP = new ImplementationA();

на

static staticsProvider SP = new ImpelentationB();

Позволяет быструю замену. Также, если вам когда-либо понадобятся два или более разных экземпляра для разных частей кода (SP1 и SP2), теперь это только одно дополнительное статическое поле и инстанция. Это две большие проблемы снятия статики. И вы все еще можете использовать экземпляры в классе или области действия функции.

Теперь путь WPF - «Если вы не можете изменить его, оберните его во что-то, что вы можете изменить!». Так как насчет опции D:

//I am not a static
public class D{
    //I am not either
    public void MethodA(){
      //But I do call one for you
      A.MethodA();
    }
}

Затем вы можете создать статическое поле:

static public D SP = new D();

Если вам нужно более одного статического провайдера? сделать другое поле. Если вам нужна другая реализация? Извлеките интерфейс (фактически VS IDE Option) или создайте абстрактный базовый класс из D. измените переменные на указанную базовую класс / интерфейс. Затем создайте класс D2, который наследует / реализует то, что вы только что создали.

Не хотите, чтобы он изменился во время выполнения? const или readonly модификаторы. Но на самом деле возможность обмена экземплярами во время выполнения может быть функцией.

2nd

Вместо того, чтобы пытаться сократить вызовы статического, как насчет сокращения версийдля MethodBX и MethodCX?

Используя делегатов, вы можете передать код для частей "beforeStatic" и "afterStatic" в качестве функций.

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

Затраты на вызов функции

Тамстоимость вызова функций. По сути, процессор должен сделать прыжок. И прыжки - все еще вещь, стоимость которой может быть измерена. Вероятно, это не будет иметь значения в целом - мы прошли время, когда мы урезали циклы процессора. Кроме того, этого можно избежать автоматически:

Собственный C ++ имеет подсказку компилятора inline .

Afaik .NET не разрешает этот элемент управления. Но у этого есть JiT и Оптимизация Компилятора. И они могут полностью перейти на ваш автоматически. И для такой функции:

public static StaticCaller() {
  MethodA();
}

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