Правила хорошего тона protected или private?

Question

[PetrW]

Где-то слышал такое правило хорошего тона, что по-умолчанию методы класса надо делать  private, если доступ к методу понадобится тогда и надо изменять на protected

Есть и альтернативная точка зрения, что если не уверен - то ставь protected так как метод может понадобится дочерним классам, и тогда не надо будет модифицировать класс.

Как в итоге лучше?

Answer 1

[Станислав Макаров]

А почему вы по умолчанию public не ставите, если выбираете между public и private? Наверное потому что вам инкапсуляция нужна?

Ситуация с дочерними классами ничем не отличается. Не стоит делать метод protected по умолчанию по той же причине, по которой его не стоит делать public по умолчанию.

Answer 2

[Константин]

Насчёт protected в случаях, когда сомневаешься, это ты зря) Ты же по сути продумываешь свою программу, знаешь примерно, что в ней используешь, а protected на ветер не бросаются. Что же насчёт private, так храни там только переменные, чтобы они были под защитой класса от внешних изменений, методы же хранят обычно под public-ом, так можно вызывать их извне класса

Итого в итоге - переменные в private
Protected же только для наследований
Методы же в public , тем самым ты дефаешь переменные, но и имеешь к ним доступ в класс.

Answer 3

[Дмитрий Еремин]

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

Comments

[Денис Загаевский]

Open-closed принцип самый непонятный (лично для меня) из SOLID. Может быть, в идеальном мире это так и работает, но в реальности - нет.

[Igor Makarov]

Open-closed определяет не видимость метода/свойства, а final оно или нет.

Answer 4

[Дон Ган]

есть принципы SOLID, где говорится, что классы должны быть закрыты для изменения и открыты для расширения

Как в итоге лучше?

лучше - как решит разработчик
в большинстве случаев из-за солида - именно protected
private нужен в ОЧЕНЬ ограниченных случаях

Answer 5

[Сергей]

Ну если подходить философски) , то класс это довольно самодостаточный кусок кода. Т.е. если что-то случилось, то ты идешь в этот класс и исправляешь или (дополняешь его - что не совсем правильно). т.е. функциональность лежит в одном месте (этакая модульность) и не размазана по коду. Все рады и поют пиво. Встает вопрос как разбить программу на такие классы. На помощь приходит принцип инверсиии зависимостей. Звучит страшно, но на деле это разработка сверху вниз. Т.е. пишешь ты работу со счетами. Понадобилось сохранять счета. Этокое хранилище. У него вырисовывается метод сохранитьсчет. Хорошо делам заглушку Хранилище, с методом сохранить. Затем по мере реализации логики, понадобился метод загрузитьсчет. вставляем в хранилище.
т.е. у нас вырисовывается интерфейс класса Хранилище который требуется для логики. И метода этого интерфейса будут все public. и ничего лишнего.
Отлично. приходит помощник, мы говорим "у меня нет время, но есть работа. нужно реализовать методы моего хранилища" Помощник берет за основу ваш интерфейс и реализовывает свою Impl. Методы интерфейса public, и остальные которые он выделил для своего удобства privat. Все рады и работа сменяется зависоном на toster.ru. но приходит начальник и говорит"wtf?!!!" ..;%:;№. "вы сделали реализацию на mysql, а у нас полклиентов работает на оракле!"
Вы берете Impl, медитируете и понимаете, что можно в принципе переписать только часть класса для оракла, а часть оставить. но люди продвинутые и понимаете, что общий код можно выделить в базовый класс. Итак у вас вырисовывается Общий класс в котором есть public, private, protected. public и protected - могут быть абстрактными. Отлично. Вы реализовываете только часть которую нужно для оракла и все готово. Более того если нужно подключить MSSQL, вы легко это сделаете.
Вот такая сказка. В ней намек - не плодите лишнего в интерфейсе. выделяйте то что нужно. Не делайте лишнего protected. только то что нужно переиспользовать потомками. Вы же не фреймворки пишите. Заранее не нужно впихивать ненужное.