The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The ideas it that you explicitly define all the variables you're going to use ahead of time so that programming becomes more logical and easier for other people to understand (you can also use tools like phpdoc to document it)

Additionally, with PHP5 you can set protection levels (public/protected/private) when you define a class property to restrict a good programming model.

Definately so, one of the reasons these constructs were introduced into PHP was to let the language evolve from "uh, but this variable appears out of nowhere" to well defined interfaces to program against.

I never use public/private/protected. If the var might be used before it setVar is called, give it a default value otherwise I wouldn't bother.

I think fundamentally the answer to all questions like these is unit testing. You won't know what target you're trying to hit until you've identified clear requirements. Testing makes you think about interfaces and behaviours rather than the implementation details which get you there. When all tests are passing, it must be OK, whatever it is.

I never use public/private/protected. If the var might be used before it setVar is called, give it a default value otherwise I wouldn't bother.

I could understand if you'd refrain from using protected because I think in most cases it promotes behaviour based inheritance instead of establishing a proper relationship. But with staying away form private you basically say "guys, poke around in my internals" while promoting data to easily go out of sync, corrupt, or just make you application crash.I know you back everything up with unit tests but I don't think its a full (or even nice) substitute for data encapsulation because it simply isn't a hundred persent fool proof. (Using private might also not be fool proof and I might be able to hack your internals via some awful methods, but at least then I know I'm willingly breaking your application).

Also, how do you handle the deprecation of variables when they're all exposed? I usually choose private as the default access modifier and only make my data available to the public if I have really good reason for doing so.

I could understand if you'd refrain from using protected because I think in most cases it promotes behaviour based inheritance instead of establishing a proper relationship. But with staying away form private you basically say "guys, poke around in my internals" while promoting data to easily go out of sync, corrupt, or just make you application crash.I know you back everything up with unit tests but I don't think its a full (or even nice) substitute for data encapsulation because it simply isn't a hundred persent fool proof. (Using private might also not be fool proof and I might be able to hack your internals via some awful methods, but at least then I know I'm willingly breaking your application).

I take the opposite approach. I rarely use private, but frequently use protected. This approach allows for the possibility of extension via inheritance by other developers. The use of private implies to me "I am smarter than you, and I know every possible way you might make use of this class in the future, and I am not going to let you inherit from me. It is my way or the highway".

I take the opposite approach. I rarely use private, but frequently use protected. This approach allows for the possibility of extension via inheritance by other developers. The use of private implies to me "I am smarter than you, and I know every possible way you might make use of this class in the future, and I am not going to let you inherit from me. It is my way or the highway".

I take the opposite approach. I rarely use private, but frequently use protected. This approach allows for the possibility of extension via inheritance by other developers.

It forces extension via inheritance as there is no way someone else can access the data they need other than by extending you class. (The .Net framework seems to be very fond of making me do that.) In the cases I considered using protected, I was usually better of making the variable public to break encapsulation completely.

There are usually two reasons for extending an existing class. Either to create a new class which is polymorphically equivalent to the base class (interface), or to inherit functionality from the base class directly (ABC). And I hope you can agree with me that the former is better from an object oriented standpoint that the latter because an ABC might leak more than just the interface (its internal state).

Using interfaces to inherit from instead of ABCs has a big drawback; code duplication. However solving that problem is usually a trivial task.

The use of private implies to me "I am smarter than you, and I know every possible way you might make use of this class in the future, and I am not going to let you inherit from me. It is my way or the highway".

That's where final classes is for. I'm not saying I'm better than everyone (hell, I know I'm not, and never will be). I'm trying to make flexible systems, something that will not happen if I expose all of its guts to everybody. It's the concept of information hiding combined with an interface that is agreed upon that lets me do that.

In general, I don't think I need protection from my children

I can't tell it better than them so I'll let the quote speak for itself.

Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation. (Gang of Four)

I take the opposite approach. I rarely use private, but frequently use protected. This approach allows for the possibility of extension via inheritance by other developers. The use of private implies to me "I am smarter than you, and I know every possible way you might make use of this class in the future, and I am not going to let you inherit from me. It is my way or the highway".

In general, I don't think I need protection from my children

I take the complete opposite approach of your opposite approach!

I have a rule for every program I write (and maintain control of): A class may only be extended if it is either abstract or "generic", (where "generic" is a doc comment for that class).

In fact, I go a step further:

All classes which are not abstract or "generic" use the final keyword.

Or, phrased yet another way:

No class should be extended unless the programmer who wrote that class wrote it with the explicit intention of it being extended.

There are all kinds of reasons for this, but the biggest one is to avoid the situation where one programmer extends another one's class, and then the first programmer changes his class, thus resulting in a broken child.

In general, parents should decide to have children (otherwise unwanted children get abused by their parents.)

I could understand if you'd refrain from using protected because I think in most cases it promotes behaviour based inheritance instead of establishing a proper relationship. But with staying away form private you basically say "guys, poke around in my internals" while promoting data to easily go out of sync, corrupt, or just make you application crash.

My line of reasoning is simple: what passing test would fail if something which is protected were made public? I can't think of a real requirement. The interface does need to be clearly defined but I'm quite happy using underscores for that. If we're trying to write terse, explicit code every dot and comma should have to justify its existence on the page. The visibility stuff just adds a lot of clutter for zero gain, in my opinion. If you've got a car you wouldn't drop CDs into the petrol tank or pour petrol into the cd player. You just wouldn't. I can't see the problem they're trying to solve.

If that's what I think about protected you can imagine how I feel about private... A programmer I knew once committed a class with private bits. We gave him a loaded revolver and left him alone in the study to do the decent thing

My line of reasoning is simple: what passing test would fail if something which is protected were made public? I can't think of a real requirement. The interface does need to be clearly defined but I'm quite happy using underscores for that.

Unit tests are not a measurement of good coding practices nor common sense. Making every variable of you class public makes you software fragile naming convention or not; mistakes are easy to make whether they are typos or not. The reason for data encapsulation is that every class should be an (almost) atomic part of the system, responsible for only it's internal state and behaviour. When your breaking that encapsulation you smudge the responsibility of the class all over the place and blur the transparency of your design. Thus making data encapsulation a keystone of object oriented programming.

If we're trying to write terse, explicit code every dot and comma should have to justify its existence on the page. The visibility stuff just adds a lot of clutter for zero gain, in my opinion. If you've got a car you wouldn't drop CDs into the petrol tank or pour petrol into the cd player. You just wouldn't. I can't see the problem they're trying to solve.

Consider the following ambiguity between some_device::$state and some_device::set_state. The problem here is that the $state variable might be set from outside because some_device::set_state could look like a normal setter if you have only the API docs, for example. Making some_device::$state private resolves the ambiguity and thus makes your product more friendly. It might remove some use cases (setting the state without initializing) but if that's true, they should've been implemented in some_device already.

If that's what I think about protected you can imagine how I feel about private... A programmer I knew once committed a class with private bits. We gave him a loaded revolver and left him alone in the study to do the decent thing

That's just plain silly, why shoot someone down because he follows common practices; just telling him he doesn't follow the project guidelines would have been enough, right?

Unit tests are not a measurement of good coding practices nor common sense.

I think they do promote both. It's a whole new perspective, led by clear and specific requirements, which cuts through a lot of confusion.

Originally Posted by Jasper Bekkers

mistakes are easy to make whether they are typos or not

That's where we differ. I'd argue this is akin to putting a sign on an aeroplane door: "passengers are advised not to exit when the plane is in flight". We do need to mark out which doors are exits and which are cupboards and toilets but I don't think proper usage needs to be enforced. Encapsulation isn't broken per se, only if someone opens the door. I might not have minded so much if we just had to type "+" and "-" but public, private and protected are an RSI too far.

That's just plain silly, why shoot someone down because he follows common practices; just telling him he doesn't follow the project guidelines would have been enough, right?

> I'm trying to make flexible systems, something that will not happen if I expose all of its
> guts to everybody. It's the concept of information hiding combined with an interface that is
> agreed upon that lets me do that.

I use private where I have to, but I do think about it before I do though; In almost all cases I was right in doing so, ie I had made the right choice. If you ignore the use of the visibility you now have with PHP5 you are basically going to break encapsulation and provide the means for a less experienced developer to come along and abuse the system to their own ends.

Using private may hinder you when you come to unit testing, but is it an hinderance? I don't think so, so the use of private indicates that you don't want to expose that part of the system for a good reason... There are means to allow you to test that privacy, so use it.

To me, ignorance of the visibility is a bad choice by the developer, and in my view that makes a bad developer as it's a sign of a proper lack of understanding of the technology, and why it's purpose really exists; Worse... It's a sign of a complete and utter lack of respect for that language, and a total disregard for it.

> It is my way or the highway

But maybe the intentions of the developer where that no one actually inherits that given class, in the first place? There are choices of course.

> Unit tests are not a measurement of good coding practices nor common sense.

Placing too much confidence on unit testing is just asking for trouble in my view; For -beep- sake, they are not the holy grail. They are but one tool; One approach to use to a better development environment, but it's only that - a better environment and nothing more. It's not the fire and forget solution some elitist members on PAD would have you believe.

They can and do go wrong; The tests are only as good as the person who done the testing. Sitting there with a smug grin on your face with the expression that you know that nothing can go wrong just because you've gotten a green bar is crazy.

Nor is using the excuse of unit testing valid for breaking fundamental object oriented methodologies. I just cannot believe the crap that is being put across on this thread!!

> All classes which are not abstract or "generic" use the final keyword.

That is the thought I have as well; Over 70&#37; of my own frameworks classes are final and they are so by design. That is just the way I like it; A couple of people who have had the privilege to work with my framework have expressed themselves, to be polite about it but I've not backed down.

It's just that way of thinking that I have that suits me more, in that I have a believe that this is the best route to take overall. I would say that a framework should be extensible, but in only so far - a framework should be able to keep it's own secrets from the world, even if I may say so, at the cost of being less flexible; Upto a point.

Otherwise you are just leaving the framework open to abuse, vandalism. If you want a flexible framework, then design that into the framework from the beginning - it is very much possible, without the use of inheritance alone, and without leaving everything public.

> All classes which are not abstract or "generic" use the final keyword.

That is the thought I have as well; Over 70% of my own frameworks classes are final and they are so by design. That is just the way I like it; A couple of people who have had the privilege to work with my framework have expressed themselves, to be polite about it but I've not backed down.

So are you saying you're forcing people into using a specific design to avoid them writing against unstable interfaces, or just because you don't think anybody should possibly use them?

I tend to leave everything protected if it's not declared public, simply because I've come across so many instances where I wanted to do interesting things that the original programmer had never considered, but
found half of the variables or methods declared private.

There are no unstable interfaces in my framework, full stop; Currently as it stands today, it's stable and has been from the outset. Sure, I continue to expand and let the framework grow but only when I'm happy to let it.

If there is something I'm happy with, that is complete but at a later date that can't easily be implemented because a class hierarchy is final then either to me, the new implementation doesn't belong in the framework, or I utilise other means to allow the implementation in the framework.

Very seldom do I implement inheritance.

Like I said, you are not reduced (crippled?) to using inheritance to add or increase flexibility, although I admit that using final does decrease some flexibility, but you gain more in other areas.

As for forcing people either one way, or another isn't a question that you should be asking. Just because I choose one approach over another doesn't mean that you are forced one way or another. There are always choices open to you, those choices of course being what you can make of the specific situation in that given context, or those what the author makes available to you.

I'm sorry you find it difficult to understand the reasoning behind why I use final but take it from my point of view please? Personally I favour developing new script for functionality that isn't currently available in the framework. If that functionality isn't already scripted into my framework, I don't mind the need to develop further.

Who knows... I may in the future, put that given development into the framework at a later date, if I find that I use it in whole, or in part in the future, but not until I reach that situation, and only then after much thought.

What is in my framework is pretty much final and thus will not be removed, and I'm pretty much happy with the design as how it stands, in regards to the approaches or techniques I use. So, if it's not a permanent part of my framework, it's otherwise part of the application.

This people, to me is how to develop a lean, bloat free framework; Sure, you have to limit the flexibility to some people, but it's those same people that would openly abuse your framework if given half the chance, either be it knowingly or unknowingly.

Like I said, a framework needs to keep it's own secrets.

Jason, whilst I would agree that inheritance has it's uses, and a part of my framework does rely on inheritance, I would summise that it's a bad choice for the entire framework to be based on an abstraction, to allow for inheritance.

But this is going off topic; If anyone is interested in discussing framework design and development... Please, by all means, start a new thread;

This people, to me is how to develop a lean, bloat free framework; Sure, you have to limit the flexibility to some people, but it's those same people that would openly abuse your framework if given half the chance, either be it knowingly or unknowingly.

My approach is to develop an application, then reduce everything down to the smallest possible common re-usable components and carry on going as long as the total code size is less than the original or justifiably larger.

Originally Posted by Dr Livingston

But this is going off topic; If anyone is interested in discussing framework design and development... Please, by all means, start a new thread;

Briefly, the current approach found in most OOP languages mixes two totally different concepts: one is of a property's visibility and the other is of a property's extensibility. In my opinion, ideally: a) all properties (attributes and methods) should be modifiable by child classes, and b) visibility should be constrained to instance objects, not to classes (except for static properties).

The last one means that all attributes should be private by default, i.e. that they could be accessed only by the instance object they belong to. Then only select ones would be declared public, which means that anything else (other instance objects as well as other classes through static methods, or even a procedural function in PHP) could access it. Furthermore, only methods (and perhaps true properties if the language supported it) could be declared public; that would then represent that object's API. Sadly, I know of no language that employs this exact approach.

I disagree with you about everything being extensible, but that part about instances having different exposure than the class definitions is brilliant. And I like the idea of having only methods be able to be public.

While I'm typing, I've always thought that "protected" was a terrible choice of word to describe what it does. (Hell, isn't "protected" practically a synonym for "private".) My word for that would have been "family".

I disagree with you about everything being extensible, but that part about instances having different exposure than the class definitions is brilliant.

Uhh...
Thanks, I guess.

Anyway, the reasoning behind everything being extensible is this: In OOP, each object represents, well, an object -- often an abstract one, but sometimes a real one (let's say, a duck). The problem is that too many times we get sidetracked by the classes, and forget that it's the actual objects that matter; and further, we get sidetracked by the implementation details and forget that they're not important.

The only situation where there should be any inheritance is when the subclass actually represent a sub-type of its parent. I know that this is a too rigid and exclusive standpoint, and in real situations I dismiss it as well, but ideally, this is all that makes sense. Imagine that we have "limp ducks", which are a subspecies of "normal" ducks, differing from them only by, say, not being able to fly. They share all their other properties, and in programming terms we say that the subclass inherits them and changes those that differ. The current "private" keyword was developed as being as rigid as it is in most modern language as a (bad) way to prevent bad programmers from doing harm, not to promote OOP principles.

Originally Posted by Rotwang

And I like the idea of having only methods be able to be public.

While I'm typing, I've always thought that "protected" was a terrible choice of word to describe what it does. (Hell, isn't "protected" practically a synonym for "private".) My word for that would have been "family".

Actually, I was thinking more along the lines of "default" (i.e. having no special keyword) and "public". Unlike most modern OOP languages, I would set "private" to be the default, with only those properties that we want exposed as "public" -- i.e. the API. This way we care only about an object's behavior, and we don't really care about its internals.

And I was partially wrong in the previous post, as there is one language that comes close to what I described, and that is Javascript.

The only situation where there should be any inheritance is when the subclass actually represent a sub-type of its parent.

Concrete class inheritance (Eg. class Foo extends Bar) really does two things at once. 1) Foo inherits the type of Bar (type inheritance) and 2) Foo inherits the implementation of Bar (implementation inheritance). It's unfortunate that the language semantics mix the two things together, since they are really two completely separate issues.

Theoretically, type inheritance is very useful, since it allows polymorphism, whereas implementation inheritance is an ugly hack. Like many ugly hacks, it's sometimes useful in the real world, even if it's impure from a scientific point of view. It can always be replaced with composition, but it may take a little more effort. The more experienced people become with OOP, the more they tend to avoid implementation inheritance, and use composition instead.

Pure type inheritance can be achieved in statically typed languages through interfaces, and in the case of dynamically typed languages such as PHP, by magic. The conclusion on this would be that inheritance is completely unneeded in PHP, unless for nasty shortcuts. Then again; Some would argue that PHP is the incarnation of ugly shortcuts in the first place.

Pure type inheritance can be achieved in statically typed languages through interfaces, and in the case of dynamically typed languages such as PHP, by magic. The conclusion on this would be that inheritance is completely unneeded in PHP, unless for nasty shortcuts. Then again; Some would argue that PHP is the incarnation of ugly shortcuts in the first place.

Good post. But in a way, if you're against implementation inheritance, then you're really against inheritance in general, and rather, in favor of using interfaces instead, right? One could say that an interface is like inheritance without the implementation, no?

My view is implementation inheritance is ok if the class being inherited from explicitly expects (and allows) it, and was created with the intention of being extended.

Also you're venturing onto the strong typing debate . (I think the worst thing about php/python is the weak typing. Oh, excuse me, "dynamic typing", the politically correct term. (Well, actually the worst thing about python is the whitespace thing, but now I'm in double perens.)) Much like the original post, one could say, as you kind of did, "why bother creating interfaces in php? it will work anyway if you don't." The original poster asked "why bother declaring public...". I want all those declarations to be required, as in java or AS 2/3...