Создание методов для всех статических классов

Мне сказал мой коллега, основанный на одном из моих классов (это класс экземпляра), который, если у вас нет полей в вашем классе (поля поддержки), просто сделайте все методы статичными в классе или сделайте класс singleton так что вам не нужно использовать ключевое слово new для вызова методов в этом классе BL.

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

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

Я не уверен, что каждый раз, когда в качестве опции вы делаете это сингл, это что-то вроде шаблона или хорошего совета, который он мне дает?

Здесь класс, о котором я говорю (просьба не пересказывать какой-либо из этого кода в этом потоке, это частный): http://www.elbalazo.net/post/class.txt

ОТВЕТЫ

Ответ 1

Существует очень мало недостатка в вызове new и создании ссылки на класс, особенно если класс не имеет состояния. Выделение происходит быстро в .NET, поэтому я бы не использовал это в качестве оправдания для статического класса.

Как правило, я считаю, что класс должен быть статичным, если класс не имеет конкретного контекста - если вы используете класс как заполнитель для методов "полезности" или неконтекстно-зависимых операций, тогда имеет смысл быть статический класс.

Если этот класс имеет конкретную потребность в контексте и смысл в конкретном смысле, то он, вероятно, не оправдывает статичность, даже если он не имеет состояния (хотя это редко). Бывают случаи, когда цель класса определяется самой ссылкой, которая предоставляет "состояние" своего рода (сама ссылка) без каких-либо локальных переменных.

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

Ответ 2

Нет абсолютного правила, когда класс должен быть статическим. Он может не иметь состояния, но вам может понадобиться его для ссылочного равенства или блокировки. Классы должны быть статичными, если их цель соответствует тому, что он реализуется как статический класс. Вы не должны следовать жестким правилам в этих ситуациях; используйте то, что вы чувствуете ".

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

Ответ 3

Отсутствие одного состояния не является основанием для статических методов. Существует много случаев, когда класс без сохранения состояния должен иметь методы экземпляра. Например, в любое время, когда вам нужно передать конкретные реализации некоторой логики между подпрограммами, гораздо проще сделать это с классами, которые имеют методы экземпляра, поскольку это позволяет нам использовать интерфейсы:

interface IConnectionProvider
{
    object GetConnectedObject();
}

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

Нет ничего плохого в том, что нужно использовать new для использования метода в классе без сохранения.

Ответ 4

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

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

Ответ 5

Классы полезности часто состоят из независимых методов, которые не нуждаются в состоянии. В этом случае целесообразно сделать этот метод статическим. Вы также можете сделать класс статическим, поэтому он не может быть создан.

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

public static class MathUtil
{
    public static float Clamp(this float value, float min, float max)
    {
        return Math.Min(max, Math.Max(min, value));
    }
}

Использование:

float f = ...;
f.Clamp(0,1);

Ответ 6

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

Сказав это, часто небольшие рутинные утилиты лучше всего выполнять с процедурной реализацией, поэтому не стесняйтесь, если это имеет смысл. Рассмотрим String.IsNullOrEmpty() отличный пример процедурной статической подпрограммы, которая обеспечивает преимущество в том, что вы не являетесь методом. (преимущество заключается в том, что он также может проверить, является ли строка нулевой)

Другим примером с другой стороны ограждения будет процедура сериализации. Он не нуждается ни в каких членах. Предположим, что у него есть два метода Write (Stream, Object) и Object Read (Stream). Не требовалось, чтобы это был объект, и статические методы могли бы быть достаточными; однако имеет смысл быть объектом или интерфейсом. В качестве объекта я мог бы переопределить его поведение или позже изменить его реализацию, чтобы он кэшировал информацию о типах объектов, которые он сериализовал. Став объектом для начала, вы не ограничиваете себя.

Ответ 7

В большинстве случаев ОК, чтобы сделать класс статическим. Но лучший вопрос: почему у вас есть класс без состояния?

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

Ответ 8

Убедитесь, что у вас есть веская причина сделать класс статичным.

В соответствии с Руководством по разработке рамок:

Статические классы должны использоваться только как поддерживающие классы для объектно-ориентированное ядро ​​структуры.

НЕ рассматривать статические классы как разное ведро.

Должна быть четкая хартия для класс.

Ответ 9

Статический класс, статические методы и класс Singleton - это три разных понятия. Статические классы и статические методы обычно используются для реализации строго служебных классов или их бездействия и, следовательно, для потокобезопасности и совместимости.

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

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

Ответ 10

Похоже, вы говорите о строго классе Utility, и в этом случае нет причин иметь отдельные экземпляры.

Сделать эти методы утилиты статическими. Вы можете сохранить класс как обычный объект, если хотите (чтобы можно было добавить дополнительные методы экземпляра/информацию о состоянии).