Класс с отдельным методом — лучше всего приближается?
11 ответов
Я раньше любил служебные классы, заполненные статическими методами. Они сделали большую консолидацию вспомогательных методов, которые иначе лягут вокруг порождения ад обслуживания и дублирование. Они очень просты в использовании, никакое инстанцирование, никакое распоряжение, просто fire'n'forget. Я предполагаю, что это было моей первой невольной попыткой создания сервис-ориентированной архитектуры - много сервисов не сохраняющих состояние, которые просто сделали их задание и ничто иное. Поскольку система растет однако, драконы прибыть.
Полиморфизм
Говорит, что у нас есть метод UtilityClass. SomeMethod, который счастливо шумит вперед. Внезапно мы должны изменить функциональность немного. Большая часть функциональности является тем же, но мы должны изменить несколько частей, тем не менее. Это не был статический метод, мы могли сделать класс производной и изменить содержание метода по мере необходимости. Поскольку это - статический метод, мы не можем. Несомненно, если мы просто должны добавить функциональность или прежде или после старого метода, мы можем создать новый класс и назвать старый в нем - но это просто грубо.
Интерфейсное горе
Статические методы не могут быть определены через интерфейсы по логическим причинам. И так как мы не можем переопределить статические методы, статические классы бесполезны, когда мы должны раздать их их интерфейсом. Это представляет нас неспособный использовать статические классы в качестве части стратегической модели. Мы могли бы исправить некоторые выпуски передающие делегаты вместо интерфейсов .
Тестирование
Это в основном идет рука об руку с интерфейсным упомянутым выше горем. Поскольку наша способность чередующихся реализаций очень ограничена, мы также испытаем затруднения при замене производственного кода тестовым кодом. Снова, мы можем обернуть их, но это потребует, чтобы мы изменили значительные части нашего кода только, чтобы быть в состоянии принять обертки вместо фактических объектов.
Способствует блобам
, Поскольку статические методы обычно используются в качестве служебных методов, и служебные методы обычно будут иметь различные цели, мы быстро закончим с большим классом, заполненным некогерентной функциональностью - идеально, каждый класс должен иметь единственную цель в системе. У меня очень было бы пять временами классы, пока их цели четко определены.
сползание Параметра
Для начала, что мало милого и невинного статического метода могло бы взять единственный параметр. Когда функциональность растет, несколько новых параметров добавляются. Скоро дальнейшие параметры добавляются, которые дополнительные, таким образом, мы создаем перегрузки метода (или просто добавьте значения по умолчанию на языках, которые поддерживают их). В ближайшее время у нас есть метод, который берет 10 параметров. Только первые три действительно требуются, параметры 4-7 дополнительные. Но если параметр 6 определяется, 7-9 требуются, чтобы быть заполненным в также... Мы создали класс с единственной целью сделать то, что сделал этот статический метод, мы могли решить это, беря в обязательных параметрах в конструкторе и позволяя пользователю установить дополнительные значения через свойства или методы для устанавливания нескольких взаимозависимых значений одновременно. Кроме того, если метод вырос до этой суммы сложности, это, скорее всего, должно быть в ее собственном классе так или иначе.
Требовательные потребители для создания экземпляра классов ни по какой причине
Один из наиболее распространенных аргументов, почему требование, чтобы потребители нашего класса создали экземпляр для вызова этого отдельного метода, не нуждаясь в экземпляре впоследствии? Создание экземпляра класса является очень очень дешевой операцией на большинстве языков, таким образом, скорость не является проблемой. Добавление дополнительной строки кода потребителю является низкой стоимостью для того, чтобы положить начало намного большему удобному в сопровождении решению в будущем. И наконец, если Вы не хотите создавать экземпляры, просто создают одноэлементную обертку Вашего класса, который допускает легкое повторное использование - хотя это действительно делает требование, чтобы Ваш класс был не сохраняющим состояние. Если это не является не сохраняющим состояние, можно все еще создать статические методы обертки, которые обрабатывают все, все еще принося Вам всю пользу в конечном счете. Наконец, Вы могли также сделать класс, который скрывает инстанцирование, как будто это был одиночный элемент: MyWrapper. Экземпляр является свойством, которое просто возвращает новый MyClass ();
Только соглашение ситхов в абсолютных понятиях
, Конечно, существуют исключения к моей неприязни к статическим методам. Истинные служебные классы, которые не представляют угрозы для чрезмерного увеличения размера, являются превосходными случаями для статических методов - Система. Преобразуйте как пример. Если Ваш проект является одноразовым без требований для будущего обслуживания, полная архитектура действительно не очень важна - статичный или не статичная, действительно не имеет значения - скорость разработки делает, как бы то ни было.
Стандарты, стандарты, стандарты!
Используя методы экземпляра не сдерживает Вас от также использования статических методов, и наоборот. Пока там рассуждает позади дифференцирования, и оно стандартизировано. Нет ничего худшего, чем просмотр бизнес-слоя, растягивающегося с различными методами внедрения.
Я просто сделал бы все в конструкторе. как так:
new MyClass(arg1, arg2, arg3);// the constructor does everything.
или
MyClass my_object(arg1, arg2, arg3);
Ваш класс может быть сделан статичным?
Если так, тогда я сделал бы его классом 'Утилит', что я вставлю все свои классы с одной функцией.
Если этот метод является не сохраняющим состояние, и Вы не должны раздавать его, то он имеет большую часть смысла определить его как статичный. Если ДЕЙСТВИТЕЛЬНО необходимо раздать метод, Вы могли бы рассмотреть использование делегат , а не один из Ваших других предложенных подходов.
Я действительно не знаю то, что ситуация здесь, но я посмотрел бы на помещение ее как метод в одном из классов, что arg1, arg2 или arg3 принадлежат - Если можно семантически сказать, что один из тех классов владел бы методом.
Я сказал бы, что формат Статического метода будет более оптимальным вариантом. И я сделал бы класс статичным также, тот способ, которым Вы не должны будете волноваться о случайном создании экземпляра класса.
Если Вы не должны сохранять состояние из объекта, то нет никакой потребности инстанцировать его во-первых. Я пошел бы с единственным статическим методом, которому Вы передаете параметры.
я также предостерег бы от гиганта класс Utils, который имеет десятки несвязанных статических методов. Это может быть дезорганизовано и громоздкое второпях. Лучше иметь много классов, каждого с немногими, связанными методами.
Если нет никакой причины иметь экземпляр класса, созданного для выполнения, функция тогда используют статическую реализацию. Почему заставляют потребителей этого класса создать экземпляр, когда каждый не нужен.
Я предпочитаю статический путь. Так как Класс не представляет объект, не имеет смысла делать экземпляр из него.
Классы, которые только существуют для их методов, нужно оставить статичными.
Я предположил бы что ее твердое ответить на основе предоставленной информации.
Мой пищеварительный тракт, что, если Вы просто собираетесь иметь один метод, и что Вы собираетесь выбросить класс сразу, затем сделайте его статическим классом, который берет все параметры.
, Конечно, его твердое для сообщения точно, почему необходимо создать единый класс только для этого метода. Действительно ли это - типичная "Ситуация с" класса утилит, как большинство предполагает? Или Вы реализуете своего рода класс правила, которого могло бы быть больше в будущем.
, Например, имейте тот класс быть сменными. Тогда Вы хотели бы создать Интерфейс для своего одного метода, и затем Вы захотите иметь все параметры, переданные в интерфейс, а не в конструктора, но Вы не захотите, чтобы он был статичен.
Для простых приложений и внутренних помощников я бы использовал статический метод. Для приложений с компонентами мне нравится Managed Extensibility Framework. Вот выдержка из документа, который я пишу, чтобы описать паттерны, которые вы найдете в моих API.
- Услуги
- Определяется интерфейсом
I[Имя службы]. - Экспортируется и импортируется по типу интерфейса.
- Единая реализация обеспечивается хост-приложением и потребляется внутри и/или с помощью расширений.
- Методы на сервисном интерфейсе являются потокобезопасными.
- Определяется интерфейсом
В качестве надуманного примера:
public interface ISettingsService
{
string ReadSetting(string name);
void WriteSetting(string name, string value);
}
[Export]
public class ObjectRequiringSettings
{
[Import]
private ISettingsService SettingsService
{
get;
set;
}
private void Foo()
{
if (SettingsService.ReadSetting("PerformFooAction") == bool.TrueString)
{
// whatever
}
}
}