Не следует использовать частные функции. Вот что вам следует делать вместо этого

Дружественный совет по созданию лучшей кодовой базы

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

На самом деле такого нет. Существует множество примеров частных полей, но ни одного для частных функций.

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

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

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

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

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

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

Пример

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

Извлечение проверки электронной почты в другой класс

При извлечении подтверждения электронной почты в EmailValidator автоматически предоставляются следующие преимущества:

• Отсутствие шума низкоуровневых деталей
• Весь класс написан на одном уровне абстракции
• EmailValidator можно тривиально использовать повторно
• Поведение проверки электронной почты можно протестировать изолированно
• LoginPresenterМожно проверить, предоставив имитацию EmailValidator

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

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

Заключение

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

Для дальнейшего чтения:
https://carlosschults.net/en/are-private-methods-a-code-smell/

Уровень кодирования

Спасибо, что стали частью нашего сообщества! Подпишитесь на наш канал YouTube или присоединитесь к Интервью по программированию Skilled.dev.