Статический вспомогательный класс против статического метода в классе экземпляра против метода расширения - PullRequest
Новая
       2

Статический вспомогательный класс против статического метода в классе экземпляра против метода расширения

4 голосов
/ 06 сентября 2011

Я ищу наилучший подход к решению следующей проблемы.

Мне бы хотелось, чтобы мнения людей о том, какой метод (ы) они использовали и почему, использовали следующий сценарий:

У меня есть Class, который создается фабрикой, когда указан DateTime.

Какой подход я должен использовать?

статический класс "помощника": Class c = ClassHelper.GetClass(DateTime);
статический метод для типа экземпляра: Class c = Class.GetClass(DateTime);
статический класс / метод расширения: Class c = DateTime.GetClass();

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

Есть ли какие-то соображения, которые я должен учитывать, когда дело доходит до модульного тестированияили организация тестов?

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

Ура,

Джеймс

Ответы [ 2 ]

5 голосов
/ 06 сентября 2011

У меня есть класс, который создается фабрикой, когда указан DateTime. Какой подход я должен использовать?

  1. статический «вспомогательный» класс: Class c = ClassHelper.GetClass (DateTime);
  2. статический метод для типа экземпляра: Class c = Class.GetClass (DateTime);
  3. статический класс / метод расширения: Class c = DateTime.GetClass ();

Моя рекомендация состоит в том, чтобы следовать принципу , самой простой вещи, которая могла бы работать и связность кода .

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

3 голосов
/ 06 сентября 2011

Проблема любого статического решения заключается в том, что другие классы могут быть тесно связаны с вашим классом.

Скажем, ClassB хочет экземпляр Class.Он вызывает статический метод Class.GetClass(DateTime) в своем методе.Теперь скажите, что вы хотите протестировать ClassB независимо от класса.(Или, если вы не участвуете в тестировании, вы хотите повторно использовать ClassB в другом месте с другой реализацией Class и не хотите ссылаться на всю иерархию.) Как вы это делаете?несколько решений этой проблемы. Контейнеры IoC и абстрактный фабричный шаблон - это два.Обычно они включают интерфейсы (которые являются вашими друзьями).Они также могут быть излишними;это зависит от того, что делает ваш класс и как он будет использоваться.

...