Существует ли эмпирическое правило для того, когда кодировать статический метод по сравнению с методом экземпляра?

Я не думаю, что любой из ответов добирается до сути причины OO того, когда выбрать один или другой. Несомненно, используйте метод экземпляра, когда необходимо иметь дело с членами экземпляра, но Вы могли обнародовать всех своих участников и затем кодировать статический метод, который берет в экземпляре класса как аргумент. Привет C.

Необходимо думать о сообщениях объект, который Вы разрабатываете, отвечает на. Это всегда будут Ваши методы экземпляра. Если Вы будете думать о своих объектах этот путь, то у Вас почти никогда не будет статических методов. Статические участники в порядке при определенных обстоятельствах.

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

Если реализация метода может быть выражена полностью с точки зрения открытого интерфейса (без downcasting) Вашего класса, то это может быть хороший кандидат на статический "служебный" метод. Это позволяет Вам поддерживать минимальный интерфейс, все еще обеспечивая удобные методы, что клиенты кода могут использовать много. Как Scott Meyers объясняет, этот подход поощряет инкапсуляцию путем уменьшения объема кода, на который повлияло изменение во внутренней реализации класса. Вот другая интересная статья Herb Sutter, выбирающего независимо станд.:: basic_string, решающий, какие методы должны быть участниками и что не было должно.

На языке как Java или C++, я признаю, что статические методы делают код менее изящным, таким образом, существует все еще компромисс. В C# дополнительные методы могут дать Вам лучший из обоих миров.

Если операция должна будет быть переопределена подклассом по некоторым причинам, то, конечно, это должен быть метод экземпляра, в этом случае, необходимо будет думать обо всех факторах, которые входят в разработку класса для наследования.

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

Если Вы сохраняете состояние (значение) объекта, и метод привык к доступу, или измените состояние затем, необходимо использовать метод экземпляра.

Даже если бы метод не изменяет состояние (служебная функция), я рекомендовал бы Вам использовать метод экземпляра. Главным образом, потому что этот способ, которым у Вас может быть подкласс, которые выполняют другое действие.

Для остальных Вы могли использовать статический метод.

:)

Вашим выбором по умолчанию должен быть метод экземпляра.

Этот поток выглядит релевантным: Метод может быть сделан статичным, но должен он? Различие между C# и Java не повлияет на свою уместность (я думаю).

Если это использует переменную экземпляра, это должен быть метод экземпляра.

В противном случае Вам решать, но если Вы оказываетесь с большим количеством статических методов и/или статических непоследних переменных, Вы, вероятно, хотите извлечь весь статический материал в новый экземпляр класса. (Набор статических методов и участников является одиночным элементом, но действительно раздражающий, имея реальный одноэлементный объект был бы лучше - регулярный объект, что, оказывается, существует один из, лучшее!).

В основном эмпирическое правило - то, если оно использует какие-либо данные, характерные для объекта, экземпляра. Таким образом, Math.max статичен, но BigInteger.bitCount () является экземпляром. Это, очевидно, становится более сложным, как Ваша модель предметной области делает, и существуют промежуточные случаи, но общее представление просто.

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

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

проблема со статическими методами - то, что Вы повреждаете один из базового объекта Ориентированные принципы, поскольку Вы связаны с реализацией. Вы хотите поддерживать открытый близкий принцип и иметь Вашу реализацию класса интерфейс, который описывает зависимость (в поведенческом абстрактном смысле), и затем имейте свои классы, зависят от того интерфейса. Намного легче расшириться после того продвижения точки...

По моему скромному мнению, если можно сделать это статическим методом (не имея необходимость изменяться, это структура) затем делают это статическим методом. Это быстрее, и более просто.

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

Обычно Вы не должны добавлять функциональность, как только Вы воображаете использование одним днем (тот способ, которым безумие находится), необходимо только добавить функциональность, Вы знаете, что Вам на самом деле нужно.

Для более длительного объяснения...

http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

http://c2.com/xp/YouArentGonnaNeedIt.html

My static methods are always one of the following:

1. Private "helper" methods that evaluate a formula useful only to that class.
2. Factory methods (Foo.getInstance() etc.)
3. In a "utility" class that is final, has a private constructor and contains nothing other than public static methods (e.g. com.google.common.collect.Maps)

I will not make a method static just because it does not refer to any instance variables.