Private методы и свойства

Question

[Kir ---]

В каких случаях нужно предпочитать использовать private вместо protedted для методов и свойств класс?
Private полностью лишает нас возможности расширять класс — что на мой взгляд не логично.
У кого какие мысли или может уже кто-то знает ответ?

Comments

[Kir ---]

Немного подправлю вопрос, а то он, похоже, немного не понятен.
Для чего используется private понятно, но не ясно, в каких случаях необходимо его использовать, когда он оправдан?

Answer 1

[skvot]

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

Comments

[Kir ---]

Почему? Публичный интерфейс, не меняется. А вот смысл ограничивать доступ наследнику, не ясен.

[skvot]

Минимизация доступности — одно из основных поддерживающих инкапсуляцию правил.

[Kir ---]

Я могу сказать, что инкапсуляция скрывает реализацию и минимизирует интерфейс для клиента. Потомок в данном случае не является клиентом.

[EugeneOZ]

Потомок является клиентом. Потомок если использует переменные родителя, может внести изменения в работу с данными у родителя, что может породить ошибку или зависимость. habrahabr.ru/post/136560/

[Kir ---]

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

Есть небольшой пример:
Класс родитель работает со списком значений.
Класс потомок работает с отфильтрованным списком значений.
В каждом методе класса родителя используется получение списка значений через getter.
В классе потомка невозможно переопределить getter, т.к. для него не доступно свойство.
Что делать? Переписывать полностью?

[Сергей Протько]

Я лично приватными делаю те методы, которые необходимы только для внутреннего использования методами, реализующими интерфейс или же решающими определенную задачу. Фактически в этом случае потомкам должно быть без разницы как реализованы эти методы и перегружать их им нету необходимости. Если есть необходимость переопределить логику работы — достаточно переопределить тот самый public/protected метод и вызывать там метод предка в нужный момент.

[Kir ---]

Извините, не могли бы вы свой подход адаптировать под мой пример выше? А то я не совсем понимаю вашу мысль.

[OpenMinded]

В вашем примере класс-потомок не нужен. Список должен приходить извне — полный или отфильтрованный. Попробуйте поменьше думать о наследовании и побольше о композиции.

[Kir ---]

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

Однако если абстрагироваться от задачи и только рассматривать проблему, что можете сказать?

[OpenMinded]

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

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

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

Что касается проблемы использования private или protected, то для полей — всегда private, для методов protected обычно используется только если есть какой-то кусок функциональности, который не должен быть публичным, но который потомки могли бы вызывать в определенный момент. Модификацию поведения через protected virtual лучше не делать вообще.

Answer 2

[OpenMinded]

Если кратко, то лучше вообще забыть быть втройне осторожным с protected и особенно protected virtual, когда вы что-то проектируете. Проблемы будут как раз из-за того, что это не входит в интерфейс и почти всегда нарушает два принципа из SOLID, а именно Open/closed principle и Liskov substitution principle.

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

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

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

Comments

[Kir ---]

Проблемы будут как раз из-за того, что это не входит в интерфейс и почти всегда нарушает два принципа из SOLID, а именно Open/closed principle и Liskov substitution principle.

Это опять же можно принимать к системе, которую мы отдаем третьим разработчикам с описанием API.
Спасибо, ваша мысль в том же направлении(что и выше в комментариях), и мне кажется, что истина уже где то рядом :)

Answer 3

[knekrasov]

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

Делать публичными стоит только те методы, которые соответствуют смысловой абстракции.

Comments

[Kir ---]

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

[resurtm]

как выяснить, если мы не знаем о том, как люди будут его расширять?

Вы сами не понимаете того, как будет работать ваш класс и как с ним должны работать люди?
Вообще, предложение-вопрос попахивает троллингом.

[Kir ---]

Ни сколько это не троллинг, это вопрос который мне интересен(и важен).
Я знаю как работает мой класс, но я не знаю как захотят его расширить.

[knekrasov]

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

Остальное придет только с опытом. Ну и плюс чтение чужих исходников тоже помогает.

[Kir ---]

1. Лучше не давать советы про опыт. Как минимум это не прилично, как максимум, можете не попасть в просак говоря это человеку, у которого опыта больше вашего(я не говорю про себя, я говорю в общем)
2. У вас очень интересная мысль. Вы воспринимаете расширение класса, как API. А значит все что вы говорите, касается безопасности системы. И если подытожить, то получаем, что скрывать свойства и методы для наследников нужно в том случае, если это угрожает безопасности системы. В случае с framework такой необходимости я пока не наблюдаю.
В случае с SDK — это необходимо.

[Kir ---]

Кстати, спасибо за мысль про API

[OpenMinded]

А значит все что вы говорите, касается безопасности системы.

Модификаторы уровня доступа придумали не для защиты от идиотов или злоумышленников. Они сделаны для удобства нормальных пользователей (программистов), чтобы они знали и видели ровно столько, сколько требуется и не более. Чтобы было видно, где заканчивается абстракция и начинается реализация.

[knekrasov]

1. Лучше не давать советы про опыт. Как минимум это не прилично, как максимум, можете не попасть в просак говоря это человеку, у которого опыта больше вашего(я не говорю про себя, я говорю в общем)

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

Про свой опыт я не сказал ни слова и не собирался. Извините, если это вас задело.

[Kir ---]

хорошо, простите за несдерженность

Answer 4

[AR1ES]

Как сказали выше, private нужно использовать для тех переменных, которые не нужны будут наследникам класса для использования в явном виде.
Я, например, все переменные делают private и только при острой необходимости перевожу их в protected. Но чаще я делаю просто protected геттеры и сеттеры для этой переменной, т.к. как может возникнуть необходимость контролировать доступ к ней и из дочерних классов.
К тому же не забывайте, что в разных языках protected ведет себя по-разному. К примеру, в C++ protected позволяет дочерним классам иметь доступ к переменной, а в Java — дочерним классам, а так же всем остальным классам, находящимся в этом же пакете.

Comments

[AR1ES]

Слишком долго я набирал сообщение, чтобы потом до конца понять суть проблемы…
Собственно конкретный пример сейчас не приведу. Но ведь вполне явно что может возникнуть необходимости из дочернего класса только читать значение некоторой переменной, но не присваивать ей значения. Тогда переменная как раз должна быть объявлена как private, а так же должен быть определен protected геттер для нее.

[Kir ---]

Про поведение private в разных языках не знал — спасибо.
Есть проблема, при подходе открытия доступа в момент острой нужды. Вам необходимо хорошо знать родительский класс. Т.е. при реализации наследника, вам нужно хорошо знать внутреннюю кухню, для того что бы позволить себе изменить область видимости свйоства/метода в родители. Что по сути, нарушение инкапсуляции. Да и не всегда это возможно, например когда вы используете framework.
Предположим вы его разработчик. Вы понимаете, что пользователи будут расширять его возможности. При этом использования private методов или свойств может сильно урезать расширение. Как поступать, когда использовать private, а когда protected?

[AR1ES]

Вот и примерчик вспомнился. Только вчера писал потоковую оболочку для работы со специфическим буфером. Так вот в этом классе есть private массив байт, в который предварительно считываются данные из буфера, а потом этот массив конвертируется в необходимое значение. При этом из-за большого количество записей чтения, постоянно выделять память и освобождать непосредственно внутри метода не имеет смысла из-за накладных расходов.
Потом в связи с тем что возможна передача шифрованных данных, мне пришлось создать наследник этого класса, реализующий логику дешифрования. При этом сам процесс чтения данных то не изменился, добавилось только дополнительное преобразование данных после чтения.
Теперь вернемся к private массиву. Он используется только в родительском классе. С точки зрения его абстракции, дочерние классы не должны знать как он считывает данные, они только знают, что есть набор методов для чтения, которые они могут использовать или переопределять. К тому же более того, если бы дочерний класс знал об этом массиве и попытался бы его изменить, то все просто перестало бы функционировать корректно.
Вывод: private должны быть как минимум все переменные, которые не относятся к асбтракции класса. Но и опять же повторюсь, что еще лучше, чтобы все переменные были private, а для необходимых просто определять protected геттеры и сеттеры. А public и protected стоит объявлять только константы при необходимости.

[AR1ES]

… При этом использования private методов или свойств может сильно урезать расширение. Как поступать, когда использовать private, а когда protected?

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

[Kir ---]

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

Да. Другой разработчик хочет адаптировать framework под себя и изменить под себя поведение счетчика. И это нормально.

Где то в воздухе летает знание о том, когда это надо запретить, а когда разрешить, но пока я еще не могу это понять :(

[AR1ES]

Только тут ничего даже близкого с адаптацией нет. Изменение работы фрейморка — дело разработчиков фреймварка. А вот адаптация его под себя и расширение его возможностей — Ваша задача. И она не подразумевает модификацию самого фреймворка вами :)
Продолжим немного пример. Допустим класс со скрытым счетчиком называется A. Допустим у него есть некоторый final (нельзя переопределить — из Jav) метод, возвращающий значение этой переменной.
Какой-то другой класс B в ядре фреймворка вполне может знать, как работает счетчик в A (что с точки зрения ООП не совсем корректно), и на основании этого знания выполнять другие свои функции.
Допустим переменная со счетчиком не скрыта и вы в наследнике A изменяете ее значение на какое-то некорректное.
Во время работы Ваша программа падает с каким-нибудь исключением, вы смотрите стек вызовов и видите, что исключение возникло в классе B. Но вы же его не трогали и как он работает — не знаете. И что в результате? Вы начинаете писать разработчикам фрейморвка, что у них баг.

[AR1ES]

Кстати пример из окружающего мира.
Есть абстрактный класс «дерево», есть наследник «берёза». Вроде все логично, «береза» представляет из себя тоже «дерево», но расширяющая его. Если у «дерева» есть метод «расти», который предполагает деление клеток или чего там?) Логично же, что какое бы дерево ни было, все его наследники не должны следовать какой-то другой логике, отличной от деления клеток. И соответственно они не должны иметь доступ к этому методу и переопределять его.

Просто нужно видеть какая логика должна быть внутренней и явно не может быть изменена, а какая должна предоставляться наследникам. Т.е. по сути protected и private служат для той же инкапсуляции, только более низкого уровня

[Kir ---]

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

[Kir ---]

На счет писать разработчикам, что у них баг.
Я буду это делать лишь тогда, когда разберусь в чем проблема.
Либо воспроизведу его у себя на чистой установке.

Взял за правило — пока не разобрался, разработчиков не трожь. И люблю, когда к моему продукту относятся так же.

[DevMan]

Пока я не могу понять какая логика должна быть внутренней а какая нет

Это сложно объяснить, тем более дистанционно.
Все придет с опытом.

[AR1ES]

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

[Kir ---]

DevMan заранее прошу прощения за мою резку реакцию. Просто вы задели одну из тех немногих тем, которые меня выводят из душевного равновесия.

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

[DevMan]

Я не единственный, кто упомянул про опыт и не зря упомянул «дистанционно».
Сидели бы вы со мной в одной комнате, я бы и объяснил и показал, но тратить время на печатание лекций я себе позволить не могу.

[Kir ---]

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

Answer 5

[defuz]

Private оправдан в тех случаях, если неправильное переопределение метода или атрибута наследником может привести к появлению некорректного состояния объекта (реализации нарушения инкапсуляции).

Ваша ошибка в том, что вы сравниваете protected в первую очередь c private, хотя на самом деле разница между protected и public намного меньше, чем между private и protected.

Рассматривайте public и protected как аpi вашего класса. Тольк public — это внешний api (для пользователей класса), а protected — внутренний (для наследников класса).

Comments

[Kir ---]

Private оправдан в тех случаях, если неправильное переопределение метода или атрибута наследником может привести к появлению некорректного состояния объекта (реализации нарушения инкапсуляции).

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

Ваша ошибка в том, что вы сравниваете protected в первую очередь c private, хотя на самом деле разница между protected и public намного меньше, чем между private и protected.

Как у меня может быть ошибка, если я задаю вопрос?

[OpenMinded]

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

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

[Kir ---]

Состояние открыто для потомков, а не открыто вообще.
Потомок это такой же объект, со своим состоянием.

[OpenMinded]

Для родительского класса не важно, для кого открыто его состояние. Если оно открыто, то на него уже могут быть зависимости. Лучше эти зависимости формализовать через интерфейс.

[Kir ---]

Для родительского класса не важно, для кого открыто его состояние.. Если оно открыто, то на него уже могут быть зависимости.

И как это противоречит тому, что я сказал?

Хотя в принципе, я во многом с вами согласен.

Answer 6

[Gero]

Пример: класс из сторонней библиотеки, который наследуется в вашей программе. В течение жизненного цикла вашей программы вы можете обновлять библиотеку на более новую версию, при этом ее внутренне устройство может меняться (private-методы), а интерфейсы, выставленные наружу — нет (в т.ч. и protected-интерфейсы). А вот если какие-то методы были объявлены как protected, то значительно изменять их поведение или декларацию — уже нельзя.

Answer 7

[kocherman]

Не можете придумать пример? Вот только сейчас программирую класс клиента к серверам http и https. Предположим, есть класс Client, обобщающий HttpClient и HttpsClient. На тот класс ложится транспортная работа между приложением и протоколом. Внутри описания процессов работы класса Client часто используются функции, которые относятся непосредственно к уровню абстракции данного класса (соответственно, имеют доступ private). Например, сериализация массива заголовков запроса и его последующая отправка. То есть данная функция участвует в алгоритме Client, при этом такую функцию использовать где-либо еще бессмысленно, в том числе и в дочерних классах HttpClient и HttpsClient.

Answer 8

[gro]

Я могу сказать, что инкапсуляция скрывает реализацию и минимизирует интерфейс для клиента. Потомок в данном случае не является клиентом.

Потомок в данном случае является клиентом.
Есть класс и есть два способа его использовать — 1. работать с его экземпляром. 2. расширить его.
В классе прописывается, как интерфейс его непосредственного использования (public), так и интерфейс его расширения (protected).

Comments

[Kir ---]

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

[gro]

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

[Kir ---]

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

[gro]

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

[Kir ---]

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

[OpenMinded]

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

[Kir ---]

Честно, пытался понять, как из тезиса следует вывод — не смог.
Смена области видимости метода с private на protected никак не влияет на то, что родительский класс чего то лишиться.

[OpenMinded]

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

Изменение полей и методов с private на protected не решает проблему непродуманного интерфейса, а скрывает ее, заставляя реализовывать этот интерфейс определенным способом.

Answer 9

[Глеб Старков]

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

Comments

[Kir ---]

Мне не нравится такое :)
Я более чем уверен, что решение есть, просто мы его не понимаем.
Этот же случай был и для уровня абстракции, который все же нашелся

[Глеб Старков]

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