Лучше всего использовать частные методы или защищенные методы?

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

В общем, если вы не разрабатываете для наследования, вы должны запретить его.

Ответ 4

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

Я думаю, что это сводится к вопросам: "Все ли запрещено, если только это не разрешено" или "Разрешено все, если только специально запрещено".

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

Ответ 5

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

Не позволяйте людям прикасаться к вашим частям:)

Ответ 6

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

Ответ 7

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

Не беспокойтесь о том, что может произойти в будущем.

Ответ 8

Если реализованная вами функция относится к классу и не должна использоваться вне контекста этого класса, не позволяйте ей наследоваться. Например, если бы у нас была иерархия животных, и у одного из животных было что-то невероятно уникальное для них, скажем, "layEggsInSand()", как черепаха. Это может быть совершенно уникальным для черепахи (черепаха, что бы ни было!) Поэтому не должно быть унаследовано каким-либо другим животным. В этом контексте мы бы сказали, что это личное. С другой стороны, если функция "walk()", то она не уникальна, поэтому она должна быть наследуемой.

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

Ответ 9

Как сказано, если вы собираетесь продлить класс позже, вы всегда сможете его изменить.

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

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

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

Пример

interface sound {
 public function makeSound();
}

class bark implements sound{
 public function makeSound() {
   return "Bark!!!";  
 }
}

class mew implements sound{
 public function makeSound() {
   return "Mewmew!!!";  
 }
}

class forLeggedAnimal {
  private $sound;

  public function forLeggedAnimal($sound){
    $this->sound = $sound;
  }

  public function eat(){
    echo $this->sound->makeSound();
  }

}

$cat = new forLeggedAnimal(new mew());
$dog = new forLeggedAnimal(new bark());

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

/Peter

Ответ 10

Обычно я использую private в очень специфическом случае, когда метод/переменная является очень внутренним и не должен быть прочитан или написан каким-либо другим подклассом (так почти никогда не бывает). Единственный случай, когда я использую приватную переменную, - это пример:

final public function init():void
{
    if(!_initialized)
    {
        _init();
        _initialized = true;
    }

}

protected function _init():void
{
    // specific code.
}

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

• желаемое поведение еще не реализовано или завершено
• Я не могу использовать метод, потому что он закрыт
• Я не могу изменить этот метод, потому что он закрыт

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

  = на концах вы почти меняете весь аксессор на защищенный, чтобы получить возможность расширения класса!

Таким образом, если вы считаете, что этот класс может быть расширен, предпочтительнее защищать все, кроме особо конкретного случая (если вы считаете, что конкретный метод следует использовать, но не изменять, используйте final protected).

Если вы считаете, что этот класс не должен быть расширен в любом случае: используйте private.