Question

I had convenience methods littered all over the place. I have now pushed these in to a couple of helper classes and I made the helper classes protected members of my layer supertypes.

Everything was going along swimmingly until I came to Zend View. I have extended Zend View to make my layer supertype but when I try to attach a protected member it throws a:

Zend View Exception: Setting private or protected class members is not allowed.

Firstly, why would such members not be allowed? Any ideas? Secondly, have you circumvented it in the past? And how did that go? (It seems that the framework detects protected members by the presence of a leading underscore. This seems a bit hit-and-miss, and also easy to get around).

Note - I'm not saying that I would circumvent it. I'm just trying to find out what others have done in the past (since it seems an odd constraint).

It's an important point for me since I am using traits to bring the helpers and associated proxy methods into each superclass. I don't want to maintain a separate trait just for the View. Alternatively, I don't want to make the helpers public members of each superclass.

Thank you!

Was it helpful?

Solution

Data encapsulation.

Underscore properties are not allowed primarily so that the developer can't accidentally overwrite View properties that are part of the framework.

This essentially protects all of the framework's View properties and allows you, the developer, free rain over any public properties you wish to set.

The authors of Zend View can then be sure of two things: (1) they control (and author) the private and protected class properties and (2) you control the public properties. This makes for logical data encapsulation and maintainable class overloading.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top