Я думаю, что если позволить методам в Java быть статическими, это приведет к довольно хаотичной реализации новичками, которые не понимают ОО правильно. Мы были там и думаем об этом. Если бы методы были статическими по умолчанию, насколько трудно нам было бы понять принцип ОО?

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

NB: Дайте угадаю, вы случайно не читали Clean Code?

Если foo() не имеет никакого отношения к объекту A, тогда зачем этот метод здесь?

Статические методы все еще должны быть релевантными. Если ничего не происходит, тогда зачем вы написали метод, который не имеет с ним никакой связи?

Если foo является частным, это может быть что угодно, статическое или нет. Но чаще всего это будет не static, так как это на одно слово меньше. Затем, если вам нужно использовать состояние, потому что вы изменили код, вы можете сделать это сразу же.

Когда состояние является защищенным или публичным, зависит от того, что оно делает. Эмпирическое правило - делать его не статическим, если он не является частью поведения экземпляра, и делать его статическим, если имеет смысл вызывать его без какого-либо объекта. Если вы не уверены, спросите себя, имеет ли смысл переопределять метод в подклассе.

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

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

Конечно, это (править: функции на уровне модуля) невозможно в объектно-ориентированном языке с одной парадигмой (редактировать: например, в Java) - вот почему я такой преданный сторонник многопарадигмального проектирования языков способ. Но даже в языке, исключительно объектно-ориентированном, большинство методов будут вращаться вокруг состояния объекта и, следовательно, будут нестатичными. То есть, если ваш дизайн не имеет ничего общего с объектно-ориентированным дизайном - но в этом случае вы используете неправильный язык.

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

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

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

Я не понимаю, как многие здесь пишут о том, что что-то не так со статическими функциями в программе на Java. Если функция логически статична, сделайте ее статической. Библиотека Java имеет множество статических функций. Класс Math в значительной степени наполнен статическими функциями.

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

public class MathUtils
{
  public static float squareRoot(float x)
  {
    ... calculate square root of parameter x ...
    return root;
  }
}

Конечно, вы могли бы сделать версию «более НОП», которая выглядела бы так:

public class MathUtils
{
  private float x;
  public MathUtils(float x)
  {
    this.x=x;
  }
  public float squareRoot()
  {
    ... calculate square root of this.x ...
    return root;
  }
}

Но кроме от достижения некоторой абстрактной цели использования ООП, когда это возможно, что может быть лучше? Требуется больше строк кода, и он менее гибкий.

(И да, теперь у меня есть функция извлечения квадратного корня в стандартном классе Math. Я просто использовал это в качестве удобного примера.)

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

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

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

Вы спрашиваете: «Должен ли foo всегда быть статичным, независимо от каких-либо других соображений?» Я бы сказал: «Почти, но не совсем».

Единственная причина, по которой я могу придумать, чтобы сделать это не статичным, - это то, что подкласс хочет переопределить его.

Я не могу придумать других причин, но не исключаю возможность. Я не хочу говорить «никогда и ни при каких обстоятельствах», потому что обычно кто-то может придумать какой-то особый случай.

Если он используется только методами в A и не будет иметь никакого применения вне его, то он должен быть статическим (и, возможно, должен быть помещен в Helper Class. Сейчас он не используется вне A, но нет гарантии, что никогда не будет. В противном случае, он не должен.

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

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

Говоря о последнем вопросе, они не должны быть статическими по умолчанию, потому что необходимость писать "static" заставляет людей думать, прежде чем писать статические методы. Это хорошая практика, когда у вас есть разнородные команды (те, где Java наиболее полезна).

Я думаю, что "приватная статика" (правка: для методов) - это своего рода оксюморон в Java. На мой взгляд, основная цель статических методов - предоставить доступ к функциям вне контекста экземпляров объектов. Другими словами, они практически всегда полезны, только если они общедоступны. Если вы вызываете метод только из контекста одного экземпляра объекта и этот метод является закрытым, нет смысла делать его статическим. (править: но это не имеет практического значения).

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

Когда вы пишете статический метод, вы должны помнить, что вы собираетесь использовать его в use-site со static-import (чтобы он выглядел свободным от класса), и поэтому он должен вести себя так же, как функция, которая ничего не делает и может или не может что-то вернуть, и изолирована от состояния класса, к которому она принадлежит. Поэтому статические методы должны быть редкой ситуацией.

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

Я обычно не делаю их статичными, но, вероятно, должен. Это полезно в качестве подсказки, чтобы сообщить следующему кодировщику, что этот метод НЕ МОЖЕТ изменить состояние вашего объекта, и полезно дать вам предупреждение, когда вы изменяете метод для доступа к члену, что вы изменяете природу метода.

Кодирование - это общение со следующим кодировщиком - не беспокойтесь о запуске кода, это тривиально. Итак, чтобы максимизировать общение, я бы сказал, что если вам действительно нужен такой помощник, сделать его статичным - отличная идея. Сделать его приватным тоже очень важно, если вы не занимаетесь математикой. как класс.

Статический метод используется для идентификации метода (или переменной, если на то пошло), который имеет отношение не к объектам, созданным из этого класса, а к самому классу. Например, вам нужна переменная для подсчета количества созданных объектов. Вы бы поместили что-то вроде: 'private static int instance = 0;' а затем поместите что-нибудь в конструктор для этого класса, который увеличивает «экземпляры», чтобы вы могли их подсчитать.

Не используйте static, если можете избежать этого. Он конфликтует с наследованием (переопределением).

Также, не спрашивая, но немного связанно, не делайте методы утилиты публичными.

Что касается остального, я согласен с Мэттом Б. Если у вас много потенциально статических методов, которые не используют состояние, просто поместите их в приватный класс, или, возможно, в класс protected или package protected.

Это зависит от того, например, java.lang.Math не имеет метода, который не является статическим. (Вы можете сделать статический импорт, чтобы написать cos() вместо Math.cos()). Не стоит злоупотреблять этим, но в коде, который предполагается вызывать как утилиту, это будет приемлемо. Например, Thread.currentThread()

Нет, использование статики должно быть довольно нишевым.

В этом случае OP, скорее всего, «скрывает» состояние в параметрах, переданных в статический метод. То, как поставлен вопрос, делает это неочевидным ( foo () не имеет входов или выходов), но я думаю, что в реальных примерах вещи, которые на самом деле должны быть частью состояния объекта, будут выпадать совершенно быстро.

В конце дня каждый вызов obj.method (param) преобразуется в метод (obj, param) , но это происходит на гораздо более низком уровне, чем мы. должен быть разработан в.

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

Джошуа Блох в «Правиле 1: Рассмотрите статические фабричные методы вместо конструкторов» в Эффективная Java приводит очень убедительные аргументы в пользу того, что статические методы могут быть очень полезными. В качестве примера он приводит 32 статических фабричных метода класса java.util.Collections.

В одном случае у меня есть иерархия классов POJO, экземпляры которых могут быть автоматически сериализованы в XML и JSON, а затем десериализованы обратно в объекты. У меня есть статические методы, которые используют дженерики Java для десериализации: fromXML (String xml) и fromJSON (String json) . Тип возвращаемого POJO неизвестен априори, но определяется текстом XML или JSON. (Изначально я упаковал эти методы во вспомогательный класс, но было семантически более чистым переместить эти статические методы в корневой класс POJO.)

Еще пара примеров:

• Использование класса в качестве пространства имен для группировки связанных методов (например, java.lang.Math).
• Этот метод действительно является частным вспомогательным методом, специфичным для класса, и не требует доступа к переменным экземпляра (случай, процитированный здесь).Только не добавляйте этот -эквивалент в свой список аргументов!

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

Java объединяет концепции модуля, пространства имен, adt и класса как таковые, чтобы утверждать, что некоторая ориентированная на классы объектно-ориентированная чистота должна препятствовать использованию класса java в качестве модуля, пространства имен или adt - это нелепо.

Да, методы должны быть статическими. Чисто внутренние методы поддержки должны быть частными; вспомогательные методы защищены; а служебные функции должны быть общедоступными. Кроме того, существует огромная разница между статическим полем, статической константой и общедоступным статическим методом. Первое - это просто другое слово для обозначения «глобальной переменной»; и почти всегда следует избегать, даже посредничество с помощью методов доступа едва ли ограничивает ущерб. Во-вторых, класс java рассматривается как пространство имен для символьной константы, что совершенно приемлемо. В-третьих, класс java рассматривается как модуль для функции, как правило, следует избегать побочных эффектов или, если необходимо, ограничивать их любыми параметрами, передаваемыми в функцию. Использование static поможет гарантировать, что вы случайно не нарушите его, обратившись к членам объекта.

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

В конечном итоге java имеет очень слабые конструкции области видимости, объединяющие многочисленные концепции в рамках одного и того же синтаксиса «класс» и «интерфейс».Вы не должны столько «по умолчанию» использовать статический, как не стесняйтесь использовать возможности Java, которые предлагает для предоставления пространств имен, ADT, модулей и т. Д., Когда и когда вы чувствуете необходимость в них.

Обычно я

Выполняю эти шаги по порядку, по мере необходимости:

a) Я пишу код в методе-члене, выясняю, что я, вероятно, могу повторно использовать некоторые из этих code и

Извлечь в нестатический метод

б) Теперь я посмотрю, нужен ли этому методу доступ к состоянию, или я могу уместить его потребности в один или два параметра и оператор возврата. В последнем случае:

Сделать метод (частным) статическим

c) Если я обнаружу, что могу использовать этот код в других классах того же пакета, я

Сделаю метод общедоступным и перенесу метод в вспомогательный класс пакета с видимостью по умолчанию

Например В пакете com.mycompany.foo.bar.phleeem я бы создал класс PhleeemHelper или PhleeemUtils с видимостью по умолчанию.

г) Если я затем пойму, что мне нужна эта функциональность во всем приложении, я

перемещаю вспомогательный класс в специальный пакет служебных программ

, например. com.mycompany.foo.utils.PhleeemUtils

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

Множество интересных ответов.

Если вы отчаянно ищете правило, используйте следующее:

Если код когда-либо используется только методами экземпляра одного класса, сделайте его методом экземпляра - это просто извлечение кода из экземпляра context - который можно реорганизовать обратно в (или из) методы, которые обращаются к состоянию экземпляра.

Если код используется БОЛЕЕ ОДНОГО класса и не содержит доступа к переменным экземпляра в классе, в котором находится метод, сделайте его статическим.

Конец рассказа.

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

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

Проблема с слепым извлечением общих служебных методов в их собственные классы заключается в том, что эти служебные программы действительно следует рассматривать как новый общедоступный API, даже если он используется только исходным кодом. Некоторые разработчики, выполняя рефакторинг, не учитывают это. Перенесемся к другим разработчикам, использующим дрянной служебный класс. Позже кто-то вносит изменения в расширение под себя. Если повезет, тест или два перерыва, но, вероятно, нет.

Большинство статических методов написаны потому, что

1. Вы разбиваете сложный метод на подметоды, или
2. Вы хотите, чтобы String (или Date, или ...) имел некоторую функциональность, которой не обладает 't have

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

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

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

В любом случае, все классы java.util.Arrays являются статическими. Числовые классы Integer, Boolean, String имеют статические методы. Много статических методов. Все статические методы в этих классах либо преобразуются в экземпляры соответствующих классов, либо из них.

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

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

Должна быть последовательная причина, по которой методы делаются статичными. Не помешает следовать стандартному шаблону библиотеки Java о том, когда методы делаются статическими.

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

Поэтому разработайте модель программирования, будь то MVP, инъекции, аспектно-ориентированное программирование, уровень избегания статических методов/аффинити и т.д., и знайте, почему вы хотите их - не потому, что какой-то теоретик сказал вам, что ваша практика программирования будет нарушать принципы оо. Помните, если вы работаете в индустрии, то это всегда качество и прибыльность, а не теоретическая чистота.

Наконец, что такое объектно-ориентированный подход? Объектная ориентация и нормализация данных - это стратегии создания ортогональной информационной перспективы. Например, в прежние времена руководства IBM были написаны так, чтобы быть очень ортогональными. То есть, если часть информации была написана где-то на странице в тысячах руководств, они избегали повторения этой информации. Это плохо, потому что вы читаете, изучая, как выполнить определенную задачу, и часто встречаете концепции, упомянутые в других руководствах, и вы должны быть знакомы с "моделью данных" руководств, чтобы найти эти связующие части информации в тысячах руководств.

По той же причине OS/2 не смогла конкурировать с Microsoft, потому что концепция ортогональности IBM была основана исключительно на машинах и данных, и IBM так гордо заявляла о своей истинной объектно-ориентированности против ложной объектно-ориентированности Microsoft, потворствующей человеческой перспективе. Они забыли, что мы, люди, имеем свои собственные различные ортогональные перспективы информации, которые не соответствуют ортогональности, основанной на данных и машинах, или даже друг другу.

Если вы знакомы с топологией деревьев, вы понимаете, что можно выбрать любой листовой узел и сделать его корнем. Или даже любой узел, если вы не возражаете против многоствольного дерева. Каждый думает, что его/ее узел является корнем, в то время как на самом деле корнем может быть любой узел. Если вы думаете, что ваша точка зрения на объектную ориентацию является каноном, подумайте еще раз. Более важно минимизировать количество узлов, которые принимаются в качестве корней-кандидатов.

Должен быть компромисс между эффективностью и результативностью. Нет смысла иметь эффективную модель данных или объектов, которая вряд ли может быть эффективно использована коллегами-программистами.