Как я могу проверить класс Singleton с помощью DUnit? - PullRequest
5 голосов
/ 26 октября 2009

Или лучше использовать другой шаблон проектирования?

Ответы [ 5 ]

13 голосов
/ 26 октября 2009

Ответил на похожий вопрос несколько дней назад здесь, издеваясь над синглтоном . Оригинальный пост предназначен для C # .Net в отношении насмешек над поведением одиночки, но все равно должен применяться.

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

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

Именно эта структура, кто бы ни создавал экземпляры для потребителей, отвечает за обеспечение плавания одного и только одного экземпляра. Это на самом деле не очень большой переход от статического класса к интерфейсу [как показано в ссылке выше], вы просто теряете удобство глобально доступного экземпляра - я знаю, я знаю, глобальные ссылки ужасно соблазнительны, но Люк повернулся спиной к Темная сторона, ты тоже можешь!

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

Надеюсь, это поможет!


синглтон! = Открытый статический класс , а точнее синглтон == одиночный экземпляр

3 голосов
/ 26 октября 2009

Недостаток тестируемости является одним из основных недостатков классической модели Singleton (метод статического класса, возвращающий экземпляр). Насколько мне известно, этого достаточно для того, чтобы перепроектировать любой код, использующий Singletons, для использования другого дизайна.

Если вам абсолютно необходимо иметь единичный экземпляр, тогда Dependency Injection и запись в интерфейс, как предлагает Джонни g, определенно помогут.

1 голос
/ 03 декабря 2009

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

Учтите, что в Smalltalk (где возникло много этих паттернов), true и false были по сути одинаковыми:)

1 голос
/ 26 октября 2009

Я использую следующий шаблон , когда пишу синглтоны на основе статики, которые я могу издеваться. Код Java, но я думаю, вы поймете. Основная проблема с этим подходом заключается в том, что вы должны перевести конструктор в пакетный режим (который побеждает настоящий синглтон). В качестве дополнительного примечания: код применяется для возможности имитации вашего «статического» кода, не обязательно просто вызывая его

0 голосов
/ 27 октября 2009

Если вы должны использовать синглтон (и для этого есть причины ... но я всегда буду стараться избегать его, если это возможно) Я бы порекомендовал использовать контейнер IOC для управления им. Я не уверен, есть ли один для Delphi или нет. Но в Java вы можете использовать Spring, в .NET вы можете использовать Windsor / Castle. Контейнер IOC может содержать Singleton и может регистрировать различные реализации для тестирования.

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

...