МОК - Должны util классы со статическими вспомогательными методами быть обеспеченными электричеством с помощью МОК?
Просто попытка все еще получить мою голову вокруг принципов МОК.
Q1: Статические методы - Должны util классы со статическими вспомогательными методами быть обеспеченными электричеством с помощью МОК?
Например, если у меня есть класс HttpUtils со многими статическими методами, я должен пытаться передать его другим занятиям по бизнес-логике через МОК?
Последуйте вопросы для этого могли бы быть:
Q2: Одиночные элементы - Что относительно вещей как вход, где можно обычно получать доступ к нему через Logger.getInstance () вызов типа. Вы обычно оставляли бы это, как, и НЕ используют МОК для введения регистратора в бизнес-классы, которым нужен он?
Q3: Статические Классы - я действительно не использовал это понятие, но являюсь там любыми инструкциями для того, как Вы обычно обрабатывали бы это, если бы Вы перемещались в основанный на МОК подход.
Заранее спасибо.
3 ответа
Самое забавное в IoC заключается в том, что объекты, написанные в этом стиле, обычно не связаны с этими деталями.
Давайте использовать служебный класс в качестве примера:
public class HttpUtils
{
public static void DoStuff(int someValue)
{
// ...
}
}
В приложении, не ориентированном на IoC, вы можете использовать этот метод напрямую:
public class Foo
{
public int Value { get; set; }
public void DoStuff()
{
HttpUtils.DoStuff(Value);
}
}
Однако это связывает определение DoStuff непосредственно с его реализация. IoC стремится разделить такие детали, поэтому вместо этого мы определяем операцию самостоятельно:
public interface IDoesStuff
{
void DoStuff(int someValue);
}
Затем мы оставляем место в Foo для изменения реализации:
public class Foo
{
private readonly IDoesStuff _doesStuff;
public Foo(IDoesStuff doesStuff)
{
_doesStuff = doesStuff;
}
public int Value { get; set; }
public void DoStuff()
{
_doesStuff.DoStuff(Value);
}
}
Это разделяет Foo из HttpUtils . Реализатором концепции DoStuff теперь является деталь конфигурации, а не внутренняя зависимость (как в статическом методе).
Обратите внимание, что Foo не знает, является ли его IDoesStuff одноэлементным или нет. Это время жизни также является деталью конфигурации, а не неотъемлемой деталью Foo .
Подводя итог, можно сказать, что IoC и static обычно противоречат друг другу, поскольку IoC способствует изменениям, а static , по определению, предотвращает их. Объявите свои зависимости в своих конструкторах, и вы обнаружите, что почти никогда не использовали функциональность static .
Контейнер IoC обычно полезен для внедрения объекта, который имеет состояние; или классы или интерфейсы, которые имеют более одной реализации, даже если вторая реализация является имитацией для целей тестирования. Если ни одно из этих утверждений не соответствует действительности, вы ничего не получите от инъекции. наиболее распространенная идиома в наши дни - иметь ваш класс с интерфейсом, который может реализовать как настоящая, так и фиктивная реализация.
1) Статические методы для вспомогательных классов - Нет, они не часто вводятся IoC. Обычно это утилиты без сохранения состояния.
Чтобы использовать очень простой пример, вам не нужны две версии служебного метода с именем StringUtils.Reverse () . Вам нужен только один, и вы можете легко написать для него тесты, потому что он не имеет состояния или зависимостей, поэтому нет никакой пользы от его имитации. Пример теста:
string reversedString = StringUtils.Reverse("input");
Assert.AreEqual("tupni", reversedString)
Если утилита на самом деле не имеет состояния (например, зависит от HttpContext.Current), то вам следует сделать зависимость явной, внедрив ее, а не делая утилиту статической.
2) Синглтоны : Часто да, вводятся синглтоны. Но в IoC хорошо то, что вы меньше беспокоитесь о том, есть ли что-то одно или нет. Вы получаете гибкость в создании экземпляров, используя IoC. Решение о том, чтобы конкретный тип был одноэлементным или новым экземпляром, каждый раз становится частью конфигурации контейнера IoC, и больше ничего в коде менять не нужно.
Таким образом, одноэлементность перестает быть отдельной проблемой, которую нужно закодировать в класс (а классы, вызывающие несколько проблем, когда они не должны этого делать, - это плохо), и это становится проблемой контейнера IoC. Вы больше не кодируете класс «как одноэлементный» с чем-то особенным, например, с частным конструктором и общедоступным статическим методом GetInstance () , вы просто кодируете его для основной задачи, в то время как конфигурация контейнера IoC указывает, является ли это синглтоном или нет, или где-то посередине, например, по одному экземпляру на поток.
3) Статические классы - естественное место для статических методов. Рассмотрите возможность создания методов расширения статических методов там, где это необходимо. Вы не можете внедрить эти классы, поскольку не можете их создавать. Использование статических классов создает процедурный, а не объектно-ориентированный код. Это неплохо для небольших вспомогательных методов, но если большая часть кода подобна этому, то вы не используете мощные объектно-ориентированные функции платформы .Net.
Статические методы по определению не нуждаются в экземпляре. DI/IOC нацелен на удовлетворение интерфейсов конкретными классами, и учитывая, что ваш статический класс вместе со своими статическими методами по определению не может реализовать интерфейс или расширить класс, вопрос не имеет смысла. Нет смысла передавать класс-помощник, потому что для использования статических методов не нужен экземпляр. Ваш код всегда будет выполнять те же статические методы помощника даже без экземпляра.
В приложении на базе IOC/DI можно определить интерфейсы и иметь по крайней мере одну реализацию. Все дело в управлении экземплярами и их зависимостями.