Использование статических методов - это плохо? - PullRequest
Новая
       40

Использование статических методов - это плохо?

88 голосов
/ 15 апреля 2009

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

Я прочитал различные рекомендации (в том числе о StackOverflow), чтобы НЕ злоупотреблять статическими методами, но я все еще не понимаю, что не так с эмпирическим правилом выше.

Это разумный подход или нет?

Ответы [ 15 ]

1 голос
/ 10 сентября 2015

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

   public class BusinessService
   {

        public Guid CreateItem(Item newItem, Guid userID, Guid ownerID)
        {
            var newItemId = itemsRepository.Create(createItem, userID, ownerID);
            **var searchItem = ItemsProcessor.SplitItem(newItem);**
            searchRepository.Add(searchItem);
            return newItemId;
        }
    }

Вы видите статический вызов метода ItemsProcessor.SplitItem(newItem); Пахнет причиной

  • У вас нет объявленной явной зависимости, и если вы не копаетесь в коде, вы можете пропустить связь между вашим классом и контейнером статического метода
  • Вы не можете проверить BusinessService, изолируя его от ItemsProcessor (большинство инструментов тестирования не высмеивают статические классы), и это делает невозможным модульное тестирование. Нет юнит-тестов == низкое качество
1 голос
/ 20 сентября 2013

Если это служебный метод, неплохо бы сделать его статичным. Guava и Apache Commons построены на этом принципе.

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

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

static cutNotNull(String s, int length){
  return s == null ? null : s.substring(0, length);
}

одним из преимуществ является то, что я не тестирую такие методы: -)

1 голос
/ 15 апреля 2009

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

1 голос
/ 15 апреля 2009

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

0 голосов
/ 21 апреля 2017

Статические методы обычно плохой выбор даже для кода без сохранения состояния. Вместо этого создайте одноэлементный класс с этими методами, который создается один раз и внедряется в те классы, которые хотят использовать методы. Такие занятия легче издеваться и тестировать. Они гораздо более объектно-ориентированы. Вы можете обернуть их прокси при необходимости. Статика делает ОО намного сложнее, и я не вижу причин использовать их почти во всех случаях. Не 100%, но почти все.

Страница:
...