———

“However, the developer of ExtendedTestObject does not have the option to avoid using setNewString() if they want to set a string”

This is exactly one of the most important benefits of making attributes private. When we hide the information where and how the data is obtained from, we also create single point of control where we can assert that all access to the data is uniform and constrained in similar ways. Think invariants.

Setting attributes private also reduces the scope of them to only that class, which reduces the potential for errors.

If you’re tempted to declare a method protected, it could be that the class isn’t designed properly. Could there be a way to factor the class better, and expose only the meaningful attributes?

Note that protected attributes should be regarded in the same way as the public interface because any method using an overridable attribute can be affected by inheritance. Therefore, making attributes protected can actually make it harder to inherit from the class. Thus, overridable attributes need documentation of all uses of them in other methods, meaning that you have to document more how a method works, instead of what it does.

And of course, you can never take anything out of your public API (which includes protected attributes), unless you really want to annoy users of the class who have already extended it.

In my opinion, it’s shortsighted to refrain from using private attributes. In the long run that will cause problems and make development harder. Using protected more will not make inheritance easier but it will make more inheritance possible. And the cost of that is potential for more errors.

Guess what: The authors of ArrayObject intentionally did not expose anything of the inner workings of this object. All you get is the API consisting of only public methods, and you have to deal with it. It does not prevent you from extending it, though. So you are able to actually create a better version of all the public methods, and you can add functionality, but you cannot interfere with the inner workings.

Back to your TestObject. Making “_setString” protected does not help at all, because you also have to make the private property protected.

In fact, the right way to deal with your class is to use the API that is intended for this. Use parent::setNewString() to actually set the modified string. Or go another route and modify getString(). It is actually a good thing to do this, it is called decorator pattern.

But let’s assume for a moment that both classes are owned by a single entity. This voids the “cannot fix the bug otherwise” argument from your other posting. You can do everything you want to your classes.

But what if you do? You might want to refactor TestObject completely, all internal workings will be changed. If you exposed internals via protected methods and properties, you also have to check, more likely also change all classes that extend TestObject, because they might stop working.

A protected method is a STOP-sign: “No changes allowed here, because otherwise you will break things in other classes.” A protected method is part of the public API of this class, as I said.

Now if you write a library that anyone is intended to use, and you have no control over any extending class, the more protected methods and properties you offer, the less you can change anything in the library. Protected methods disable your ability to change things.

But of course they ENABLE the users of the class to change the class through inheritance. The question is: Is this the only pattern that can be used to change classes? I believe “no”.

I think one point of confusion for folks is the concept of extensibility. This confusion, I believe, stems from the use of the keyword “extends” to indicated that one class inherits from another. I think people mistakenly conclude from this that inheritance is the only form of extension. Others who know better might mistakenly conclude that inheritance is the preferred approach to make code extensible.

In fact, one should favor composition over inheritance. Inheritance is one way to provide extensibility, but I would argue it is actually the least preferable approach. There are many design patterns that you can use to provide extensibility without resorting to simply using inheritance.

In my comments on your previous post, I mentioned the strategy pattern and the template method pattern. Those are two examples of design patterns that will allow you to provide extensibility without just naively using inheritance.