Когда использовать статические классы в C # [duplicate]
Это не то же самое с точки зрения C # вообще ... но в скомпилированном коде переменная, объявленная как тип dynamic, обычно (возможно, всегда) соответствует CLR поле или локальная переменная типа object.
Компилятор C # отвечает за то, чтобы для любого исходного кода, использующего это значение, было применено динамическое поведение. object - это просто компилятор, используемый представлением для хранения. Он также применяет атрибут [Dynamic] , где это необходимо, так что другой код знает, что его нужно обрабатывать динамически.
Например, рассмотрим это:
public class Foo
{
public dynamic someField;
}
Полагаю, что теперь будет скомпилирован в IL эквивалент:
public class Foo
{
[Dynamic]
public object someField;
}
, если вы пишете:
Foo foo = new Foo();
foo.someField = "hello";
Console.WriteLine(foo.someField.Length);
компилятор использует этот атрибут, чтобы знать, что foo.someField динамическое, поэтому свойство Length должно быть динамически привязано.
6 ответов
Я записал свои мысли о статических классах в более раннем ответе Переполнения стека: Класс с отдельным методом - лучше всего приближаются?
я раньше любил служебные классы, заполненные статическими методами. Они сделали большую консолидацию вспомогательных методов, которые иначе лягут вокруг порождения ад обслуживания и дублирование. Они очень просты в использовании, никакое инстанцирование, никакое распоряжение, просто fire'n'forget. Я предполагаю, что это было моей первой невольной попыткой создания архитектуры для обслуживания широкого круга запросов - много сервисов не сохраняющих состояние, которые просто сделали их задание и ничто иное. Поскольку система растет однако, драконы прибыть.
Полиморфизм
Говорит, что у нас есть метод UtilityClass. SomeMethod, который счастливо шумит вперед. Внезапно мы должны изменить функциональность немного. Большая часть функциональности является тем же, но мы должны изменить несколько частей, тем не менее. Это не был статический метод, мы могли сделать класс производной и изменить содержание метода по мере необходимости. Поскольку это - статический метод, мы не можем. Несомненно, если мы просто должны добавить функциональность или прежде или после старого метода, мы можем создать новый класс и назвать старый в нем - но это просто грубо.
Интерфейсное горе
Статические методы не могут быть определены через интерфейсы по логическим причинам. И так как мы не можем переопределить статические методы, статические классы бесполезны, когда мы должны раздать их их интерфейсом. Это представляет нас неспособный использовать статические классы в качестве части стратегической модели. Мы могли бы исправить некоторые выпуски передающие делегаты вместо интерфейсов .
Тестирование
Это в основном идет рука об руку с интерфейсным упомянутым выше горем. Поскольку наша способность чередующихся реализаций очень ограничена, мы также испытаем затруднения при замене производственного кода тестовым кодом. Снова, мы можем обернуть их, но это потребует, чтобы мы изменили значительные части нашего кода только, чтобы быть в состоянии принять обертки вместо фактических объектов.
Способствует блобам
, Поскольку статические методы обычно используются в качестве служебных методов, и служебные методы обычно будут иметь различные цели, мы быстро закончим с большим классом, заполненным некогерентной функциональностью - идеально, каждый класс должен иметь единственную цель в системе. У меня очень было бы пять временами классы, пока их цели четко определены.
сползание Параметра
Для начала, что мало милого и невинного статического метода могло бы взять единственный параметр. Когда функциональность растет, несколько новых параметров добавляются. Скоро дальнейшие параметры добавляются, которые дополнительные, таким образом, мы создаем перегрузки метода (или просто добавьте значения по умолчанию на языках, которые поддерживают их). В ближайшее время у нас есть метод, который берет 10 параметров. Только первые три действительно требуются, параметры 4-7 дополнительные. Но если параметр 6 определяется, 7-9 требуются, чтобы быть заполненным в также... Мы создали класс с единственной целью сделать то, что сделал этот статический метод, мы могли решить это, беря в обязательных параметрах в конструкторе и позволяя пользователю установить дополнительные значения через свойства или методы для устанавливания нескольких взаимозависимых значений одновременно. Кроме того, если метод вырос до этой суммы сложности, это, скорее всего, должно быть в ее собственном классе так или иначе.
Требовательные потребители для создания экземпляра классов ни по какой причине
Один из наиболее распространенных аргументов: Почему требование, чтобы потребители нашего класса создали экземпляр для вызова этого отдельного метода, не нуждаясь в экземпляре впоследствии? Создание экземпляра класса является очень очень дешевой операцией на большинстве языков, таким образом, скорость не является проблемой. Добавление дополнительной строки кода потребителю является низкой стоимостью для того, чтобы положить начало намного большему удобному в сопровождении решению в будущем. И наконец, если Вы не хотите создавать экземпляры, просто создают одноэлементную обертку Вашего класса, который допускает легкое повторное использование - хотя это действительно делает требование, чтобы Ваш класс был не сохраняющим состояние. Если это не является не сохраняющим состояние, можно все еще создать статические методы обертки, которые обрабатывают все, все еще принося Вам всю пользу в конечном счете. Наконец, Вы могли также сделать класс, который скрывает инстанцирование, как будто это был одиночный элемент: MyWrapper. Экземпляр является свойством, которое просто возвращается new MyClass();
Только соглашение ситхов в абсолютных понятиях
, Конечно, существуют исключения к моей неприязни к статическим методам. Истинные служебные классы, которые не представляют угрозы для чрезмерного увеличения размера, являются превосходными случаями для статических методов - Система. Преобразуйте как пример. Если Ваш проект является одноразовым без требований для будущего обслуживания, полная архитектура действительно не очень важна - статичный или не статичная, действительно не имеет значения - скорость разработки делает, как бы то ни было.
Стандарты, стандарты, стандарты!
Используя методы экземпляра не сдерживает Вас от также использования статических методов, и наоборот. Пока там рассуждает позади дифференцирования, и оно стандартизировано. Нет ничего худшего, чем просмотр бизнес-слоя, растягивающегося с различными методами внедрения.
Для C# 3.0 дополнительные методы могут только существовать в статических классах верхнего уровня.
При использовании инструментов анализа кода (например, FxCop), он рекомендует отметить метод static, если тот метод не получает доступ к данным экземпляра. Объяснение - то, что существует увеличение производительности. MSDN: CA1822 - Mark участников как статичные .
Это - больше инструкции, чем правило, действительно...
Я действительно склонен использовать статические классы для фабрик. Например, это - регистрирующийся класс в одном из моих проектов:
public static class Log
{
private static readonly ILoggerFactory _loggerFactory =
IoC.Resolve<ILoggerFactory>();
public static ILogger For<T>(T instance)
{
return For(typeof(T));
}
public static ILogger For(Type type)
{
return _loggerFactory.GetLoggerFor(type);
}
}
Вы, возможно, даже заметили, что МОК называют со статическим средством доступа. Большинство из времени для меня, если можно назвать статические методы для класса, это - все, что можно сделать так, я отмечаю класс как статичный для дополнительной ясности.
Я использую статические классы в качестве средства определить "дополнительную функциональность", которую объект данного типа мог использовать под определенным контекстом. Обычно они оказываются служебными классами.
Кроме этого, я думаю, что "Используют статический класс в качестве единицы организации по методам, не связанным с конкретными объектами". опишите вполне хорошо их намеченное использование.
Я только использую статические классы для вспомогательных методов, но с появлением C# 3.0, я использовал бы дополнительные методы для тех.
я редко использую статические методы классов по тем же причинам, почему я редко использую одиночный элемент "шаблон разработки".