Visibility inside Contao classes

I tend to type a lot so I'll start with the question itself:
Why is Contao using the keywords private and protected? and how do I benefit from the fact Contao does it?

I've been bugged a bit by the visibility of certain properties and functions within Contao. I had an issue viewtopic.php?f=9&t=2673 which was solved by extending a Contao class. But extending Frontend means more processing needs to be done, without the processing the result would have been the same. In short; I do not understand why I need to extend a class to be able to change a property value.

Why is Contao using the php5 visibility keywords private and protected. I can see why a programmer would decide to use the keywords, but I cannot see what the actual advantage is. Some of my problems would be easier solved if all where public. And the protected keyword I just do not get because as soon as I extend a class that includes the property or anancestor class I can access it anyway at the cost of more processing power and memory being spent.

I found at least one person who seems to agree: http://aperiplus.sourceforge.net/visibility.php

It seems it isn't even implemented entirely logically (though I must admit I do not agree to what the author states, but that might just be me...): http://justinsomnia.org/2008/05/surpris ... 51-and-52/

In any case; why is Contao using the keywords private and protected? and how do I benefit from the fact Contao does it?

You might get more info on this from either the old forum ( http://contao.org/forum ) or, if you know German, from the german community - as theres a lot more seasoned developers there.
All I can say is i don't have a clue, and have yet to grasp the concepts of private, public, static, abstract, protected etc.
Half the time I'm just a monkey imitating the structure of similar modules.

Quote:

---

Originally Posted by ramjet

Half the time I'm just a monkey imitating the structure of similar modules.

---

You're not a monkey, you're a chimp :D

That is a very good question ramjet! I would also like to know why not all functions/vars are public. Maybe this somehow affects the memory?

I think it is more about maintaining a good code structure and practice. It's good practice to always restrict things to your class first and then open the methods and properties up as they are needed. If you maintain a good framework, it will help to keep things organized and ensure that extended classes will perform as expected. If you open too much up from the get-go, you have a very large potential for poorly-coded extended classes having adverse effects on on the entire framework.

I suggest reading PHP5 Objects, Patterns, and Practice. It helped me out a lot in understanding how well-structured OOP code should be planned (which Contao does very well):

http://www.amazon.com/PHP-5-Objects-.../dp/1590593804

Thanks Blair,
So you're saying this is just standard OOP practice for php5 programming?
Hit-and-Miss (or Chimp :D ) Programming I'm an expert in, but I've not learned anything about OOP yet - I guess I better start.
Any good (beginners) web resources would be also be appreciated.

I think it's more just standard OOP practice in general, not necessarily PHP. I have been tinkering with C++ for iPhone apps and learning a lot about what goes into creating well structured OO-code. You can control the evolution of an application with well structured public/protected/private methods and properties. A lot of it is giving hints to future extended classes as to how to take advantage of what has been set up before, essentially an API. You can then start to see patterns that have been set up for you, rather than simply requiring that everything be public and doing things your own way.

The more I know about Contao the more I appreciate the way things have been structured. There's a lot of thought behind it that you really start to see when you get into the framework, especially the way it is designed to be extended. Is it perfect? No, but I have not encountered a system that is...

So the short answer would be that this ensures the structure that has been setup will be used by others. They cannot bypass rules that where designed unless they'd change the original code.

This would enforce better written code for the developers that will write extensions. But of course is still not useful if one decides to just take out the keywords of all files. (Would take 5 minutes max manually, so not that much of work even to update your installation.)

Perhaps my real question is just: what is the use of the protected keyword in all cases? If I'd want to get passed that it'll be easy but takes up more processing time and memory. (see my original problem and the answer: viewtopic.php?f=9&t=2673)

Quote:

---

Originally Posted by Tru

That is a very good question ramjet! I would also like to know why not all functions/vars are public. Maybe this somehow affects the memory?

---

Thanks ;)

The use of public/protected/private all has to do with what you want other classes to be able to know about your class or object and controlling how they can interact with it. It's all about control, anticipating & eliminating problems, and also keeping a clear distinction of which functionality should be handled by which classes, which helps to build a solid framework.

Here's a good example from the book I mentioned above:

Say I have a "ShopProduct" object that has a property "price" and another property "discount". The actual price of a product will always be "price - discount" when exposed to the outside world, and we want to maintain some control over what can be presented within our ShopProduct class. By protecting these properties and instead creating a public "getPrice()" method that does the calculation of "price - discount" for us, we force external classes to use that method, thus ensuring that the correct price is always the one displayed.

The client class does not need to know about the individual "price" and "discount" properties, nor do we want to give it access to changing those properties, because that should always be handled by the ShopProduct object. Protecting those properties ensures this is the case.

So what if you want to expose those individual properties? Well, you could extend the ShopProduct object with a custom "DiscountProduct" object that has its own public methods that can return the individual price (getOriginalPrice()) and individual discount (getDiscount()) properties. What that does is allow your custom DiscountProduct to handle some specialized functions that you require without affecting the ShopProduct object itself and other subclasses. If you simply added those methods into the parent ShopProduct class, you could inevitably open up the potential for bad things to happen within other subclasses of ShopProduct that could already exist, so extending it and adding functionality is the best way to maintain integrity.

I really don't think any of this has to do with memory or processing power. It's about creating a framework. If everything was public you could have a piece of bad code in your system and it could take forever to track it down. I remember working with osCommerce years ago and its giant garbage heap of procedural code, and often I would have some crappy extension loaded that would conflict with another because they were both trying to manipulate the same data in different ways. It was a headache and a half because the framework was set up to let every piece of code have access to everything else. It sounds nice in theory, but in practice, it helps to have rules set up that force you to abide by them.

I figured out my source of confusion. I read an article that was wrong, and then mistook the problem I've referenced before because of that; total chaos. Here is the way I initially thought it would be and now again think it is:

private: can only be used in the exact instance of class that declared it. Will not be inherited
protected: can only be used in classes that extend the class that declared it.
public: can be used by any.

That makes sense to me, though I do not really understand why this solved my problem in the first place. Anyone on that?? It is solved by having a class of the same type access the variable, but not the actual instance of the object that contained that member...

osCommerce is horrible and also a faulty comparison if I recall this right. Its problem was not the visibility of functions and variables but its lack of decent expandability. People HAD to change the core code for as far as I remember. I've done it so many times and hated that I was required to keep track of what, where and why I changed anything if I was ever going to be able to update easily. Contao is not like so, but only as long as extensions do not try to change the core code. Otherwise the visibility of any member is just like a safe made of candy.

Luckily there are people that attempt to build/succeed at building great stuff like Isotope which I love as much as I do Contao. This is probably partly also because of the Contao framework. I happily and easily built an extension for Isotope, because of the framework. But sometimes I just get trapped when the easy solution would be to be able to access the variable alike in the problem I've referenced twice.

Quote:

---

private: can only be used in the exact instance of class that declared it. Will not be inherited
protected: can only be used in classes that extend the class that declared it.
public: can be used by any.

---

You are absolutely right, although protected methods/properties can also be accessed by 'siblings' as well and not just parent/childs.

Quote:

---

That makes sense to me, though I do not really understand why this solved my problem in the first place.

---

It worked in your example because you were extending Frontend, which is a parent class of PageRegular, and you were trying to access the Template object/property belonging to a PageRegular object, not just a plain old Template object. So in order to manipulate the Template object from that particular PageRegular object you needed to be doing so from either a parent/sibling class of PageRegular, which Frontend is.

Quote:

---

osCommerce is horrible and also a faulty comparison if I recall this right.

---

I just wanted to use an example of a real piece of garbage code. :D Yes, you had to manipulate the core to extend everything, so it is not a great example here... A system with a good design should not require ANY core modifications to get things done, but then you also have to think through how the responsibilities for different functions will be handled as well, which is where Model-View-Controller concepts come into play...

Ruud (or anyone) - Tucked away here http://www.contao.org/user-meeting-2009.html is a pdf called "Inside Typolight" which is worth a read if you haven't already.