Некоторое время назад я участвовал в обсуждении статических методов в объектно-ориентированном программировании. Должны ли мы их использовать? Если да, то когда? Это хорошая практика? Мы пришли к некоторым выводам, которыми я хотел бы поделиться с вами.

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

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

Плюсы:

  • простота
  • прирост производительности

Минусы:

  • тестируемость
  • расширяемость

Плюсы статических методов

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

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

Минусы статических методов

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

Расширяемость. Мы вносим изменения в программное обеспечение. Это неизбежно. Статические методы сложнее изменить. Во-первых, из-за их собственных архитектурных ограничений, одним из которых является отсутствие состояния. Во-вторых, из-за тесной связи со своими клиентами. Это делает клиентов статических методов более восприимчивыми к изменениям. Как правило, легче изменить методы экземпляра на статические, чем наоборот.

Связь

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

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

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

И последнее, но не менее важное: статические методы на самом деле не являются объектно-ориентированными. ООП связывает данные и поведение вместе. Статические методы не имеют состояния. Более того, их применение эффективно устраняет полиморфизм, поскольку мы больше не оперируем объектами.

Означает ли это, что мы должны полностью отказаться от статических методов? Нет.

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

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