Когда вы пишете частный метод против защищенного?

Ответ 1

public и protected методы формируют "интерфейс" к вашему объекту, public для разработчиков, использующих (делегируя) ваш класс, и protected для разработчиков, желающих расширить функциональность вашего объекта, путем подкласса его,

Обратите внимание, что нет необходимости предоставлять методы protected, даже если ваш класс будет подклассифицирован.

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

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

Я пошла бы за private по умолчанию, и если вы обнаружите, что вам нужно разоблачить больше методов, подумайте о том, как они будут использоваться, особенно если они виртуальны - что происходит, если они полностью заменены произвольная альтернативная функция другого разработчика - будет ли ваш класс работать? Затем создайте несколько подходящих protected, которые могут быть полезны для разработчиков, подклассифицируя ваш объект (если необходимо), а не раскрывая существующие функции.

Ответ 2

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

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

Если разработчик чувствует, что ему нужно настроить некоторые функции ваших классов, он может выбрать из ряда структурных и поведенческих моделей, чтобы сделать это, например. Декораторы, адаптеры или подклассы. Использование этих шаблонов является хорошим, поскольку оно инкапсулирует изменения в собственный класс разработчика и не оставляет ваш собственный код незатронутым. Объявив методы private, вы убедитесь, что разработчик будет обезьян с вашим классом. И это плохо.

Прекрасным примером является адаптер DB Zend Framework. Они препятствуют использованию постоянных соединений, и их адаптеры не дают никакого значения для этой цели. Но что, если вы хотите иметь это, тем не менее, и метод адаптера был отмечен private (это не так, но что, если)? Поскольку нет способа перезаписать метод, вы бы (да, вы бы) изменили код адаптера прямо внутри него класса или скопировали и ввели код в свой собственный класс адаптера, эффективно дублируя 99% класса только для смените один вызов функции. Всякий раз, когда есть обновление для этого адаптера, вы либо потеряете свои изменения, либо не получите его (в случае, если вы c & p'd). Если бы он был помечен как protected (как есть), вы могли бы просто написать подкласс pConnectAdapter.

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

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

Обновление:, так как я написал это четыре года назад, я пришел к выводу, что дефолт для защищенных, а не частных часто приводит к субоптимальным подклассам. Это происходит потому, что люди начнут использовать все, что вы предоставили, как защищенные. Это, в свою очередь, означает, что вы должны рассматривать все эти методы как API и не можете изменять их по своему усмотрению. Таким образом, лучше внимательно рассмотреть, какие точки расширения вы хотите предоставить, и сохранить все остальное частным. См. http://fabien.potencier.org/article/47/pragmatism-over-theory-protected-vs-private для аналогичного представления.

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

Я всегда делаю все методы private по умолчанию. Это означает, что интерфейс чист и прост в обслуживании.

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

Ответ 6

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

Если вы не знаете, что это будет необходимо. Если это вам хорошо (т.е. Если вы думаете, что они должны быть в состоянии), используйте protected; в противном случае используйте private.

Ответ 7

Частные члены используются для инкапсуляции внутренней работы вашего класса. Используйте их для хранения данных, которые только вы хотите получить. Например, предположим, что у вас есть поле с именем _name и getter/setter с именем GetName()/SetName (name). Возможно, вы хотите выполнить некоторую проверку синтаксиса на имени, прежде чем разрешить SetName преуспеть, иначе вы выбросите исключение. Делая _name частным, вы гарантируете, что эта проверка синтаксиса произойдет до того, как произойдут какие-либо изменения имени (если вы сами не измените _name в своем собственном классе, в вашем собственном коде). Защищая вас, вы говорите любому потенциальному будущему наследнику своего класса: "Идите вперед и обезьяна с моим полем".

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

Ответ 8

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

Кроме того, когда я чувствую себя ленивым и делаю все protected, это не является определенно опасным.