Best to use Private methods or Protected methods?

Question

In a lot of my PHP projects, I end up with classes that have non-public functions that I don't intend to extend.

Is it best to declare these as protected, or private?

I can see arguments both ways - making them private is a far more conservative approach, but it can be argued that they could be made protected later if I want the method to be extended and it makes it clear which methods are extended by base classes.

On the other hand, is using private somehow antisocial, in that it impedes a theoretical future developer from extending my code without modification?

Answer 1

I think you should only expose what you need to when you need to. This makes doing impact assessments of changes easier. i.e. If a method is private, you know the impact will be minimal if you change it.

Answer 2

I would declare the methods as private. It clearly indicates that they are not part of the public API.

Don't worry about what may happen in the future.

Answer 3

If the function you've implemented is class-specific and shouldn't be used outside of the context of that class, then don't allow it to be inherited. For example, if we had an animal hierarchy, and one of the animals had something incredibly unique to them only, say "layEggsInSand()" like a turtle. This may be wholly unique to the turtle (tortoise, whatever!) therefore shouldn't be inherited by any other animal. In this context we'd say it's private. On the other hand if the function is "walk()" then it's not unique, therefore it should be inheritable.

It seems quite fuzzy at first because most of the time things should be inherited, but there are rarer cases when they shouldn't be inherited as they're unique to that type.

Answer 4

My instinct is to keep them private, until you need them to be otherwise.

It has been argued (sadly I've misplaced the link) that making methods private is antisocial, in much the same way as making them 'final', in that it's fairly dictatorial about how people may use your code.

I'm not convinced, however, and agree that you should expose only what you really need to. The exception would be a library or toolkit, where you'll expect users to want to extend (in the general sense) your code in ways which you would never foresee. In which case making well-chosen methods protected can be seen as providing flex-points.

Answer 5

If you intend to build a class for inheritance, you must design it that way, i.e. make those methods protected that allow other developers to change the behavior of the class along the lines that you intended. Simply making all methods protected is not a very good design. Bear in mind that all protected methods become part of the public API, so if you change things later, you will break other people's code.

In general, if you're not designing for inheritance, you should prohibit it.

Answer 6

Well, the private keyword was intended with a purpose. If you don't want the variables to clutter up your inherited classes (or you don't want people playing with them in inherited classes) then why do you even consider making them protected?

Don't let people touch your private parts :)

Answer 7

Personally, I find it proper to make as much private as you possibly can. I just look at each method and ask myself if I want a derived class to be able to call it. Making everything protected leaves open the door to having methods called incorrectly.

I guess it comes down to the questions "Is everything forbidden unless specifically permitted" or "Is everything permitted unless specifically forbiddden.

One additional factor is that it's easy to make a private method protected in a future release. It's almost impossible to privatize a method once it's made protected, as you never know what other code you invalidate.

Answer 8

I generally avoid private. My reasoning goes that if you have an inheritance relation between two classes, and there are private members, then it is a very strong indicative that you should factor the private parts out into a separate object.

Answer 9

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