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

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

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

я предполагаю, что это сводится к вопросам, "Все запрещенное, если конкретно не разрешено", или "Все, разрешил если конкретно forbiddden.

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

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

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

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

не позволяют людям коснуться Ваших половых органов:)

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

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

не волнуются о том, что может произойти в будущем.

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

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

As said, if you are going to extend a class later you can always change it then.

But if you can avoid to use inheritance you should. It is better to use other patterns when designing, if possible.

Basically what to do is favor composition over inheritance and program to interfaces, not to implementations.

If you let classes just have one tightly defined purpose than you can composit objects instead of letting them inherit each other. If you use interfaces rather then inheritance you will most likley define small and effective interfaces. Then you will see that inheritance will reduce and therefore the need of protected will reduce to.

Example

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());

I know this far from a perfect example. But it illustrates the technique and you can use this in many ways. For instance you can combine this with different creational patterns to build cats and dogs, it may not be so wise to have to know if a cat barks or mews.. But anyway.. it differs from having to make a base class and then extending it with a cat and a dog, and therefor have to make the "sound" method protected or overriding the public eat method

/Peter