Частные методы среди публичных методов - PullRequest
Новая
       33

Частные методы среди публичных методов

1 голос
/ 26 апреля 2019

Страдающая бессонницей в 5 утра и т. Д., Читая «Чистый код» (Роберт Мартин).Эта книга часто рассматривается как Библия для структуры кодирования, и поэтому мне было интересно увидеть, что он предлагает аналогию с «газетой», когда дело касается упорядочения методов / функций внутри классов.В книге предлагается упорядочить функции первым открытым методом, затем связанными частными методами, затем вторым открытым методом, затем связанными частными методами (и так далее).Таким образом, структура класса может выглядеть следующим образом: 

public func openAccount()  {
    completeNameDetails()
    completeAddressDetails()
}

private func completeNameDetails() {
    ...
}

private func completeAddressDetails() {
    ...
}

public func closeAccount() {
    deleteNameDetails()
    deleteAddressDetails()
}

private func deleteNameDetails() {
    ...
}

private func deleteAddressDetails() {
    ...
}

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

Наилучшая практика: упорядочение public /Защищенный / закрытый в пределах определения класса?

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

Порядок элементов в классах: поля, свойства, конструкторы, методы

Итак, в общем, следует публичных методоввсе ли должны быть сгруппированы выше частных методов или должны следовать общедоступные методы их соответствующими частными методами (то есть публичные и частные методы смешаны)?

1 Ответ

1 голос
/ 12 июня 2019

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

В идеале, класс должен иметь только от 1 до 3 открытых методов, в противном случае он, скорее всего, делает слишком много. Я предпочитаю, чтобы мои публичные методы были сгруппированы вместе. Когда у вас есть очень маленькие классы, то, что предлагает мистер Мартин, может хорошо работать, но в реалистическом мире программного обеспечения у вас будут классы с более чем одним или двумя открытыми методами.

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

Еще одно несогласие с чистым кодом - префикс «I» для интерфейсов. Я предпочитаю, чтобы мои интерфейсы имели префикс «я». Это, однако, отдельная дискуссия.

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

...