Page 1 of 2

public, private, and protected

Posted: Mon Jul 17, 2006 10:01 pm
by Luke
Does anybody know a good article to explain the importance of the new public, private, and protected declarations in php5. Or maybe a quick and dirty explanation?

Posted: Mon Jul 17, 2006 10:05 pm
by feyd
public - anyone can modify and read them
protected - only decendants can modify and read them
private - only the class they are defined in can modify and read them

Re: public, private, and protected

Posted: Mon Jul 17, 2006 10:09 pm
by MrPotatoes
--------------------------------------------------------------------------
[edit] dude, i'm the pwn. i was right
--------------------------------------------------------------------------
The Ninja Space Goat wrote:Does anybody know a good article to explain the importance of the new public, private, and protected declarations in php5. Or maybe a quick and dirty explanation?
it should be the same as in C++. i dunno protected because i never used it. like friends, bleh

privates are great because that means if you instantiate a new class that object cannot call the classe's privates.
public is just the opposite.

so for instance

Code: Select all

<?php

	class thing
	{
		private $thing = 'oh noes';
		public  $thingy = 'oh yes!';
	}
	
	$boo = new thing;
	
	echo $boo->thing . '<BR>';	// won't work.  you'll get error
	echo $boo->thingy;			// you can get to it
?>
now for protected i'll take a stab in the dark and see if i'm right.

protected i think would mean that it's a parent's stuff that the child class can get to but an object cannot get. yes no?

Posted: Tue Jul 18, 2006 2:11 am
by timvw

Posted: Tue Jul 18, 2006 5:01 am
by Jenk
private is the 'best' to use, and then ensure for any property you wish to change, create a setter (and getter where necessary) method.

protected I only use in abstract classes, or classes I design with the intention of them being extended.. though a fair few times, I create a protected 'parental' getter instead and maintain the private declaration.

e.g.

Code: Select all

abstract class Parent
{
    private $foo;

    protected function getParentFoo ()
    {
        return $this->foo;
    }
}

class Child extends Parent
{
    public function getFoo () 
    {
        return $this->getParentFoo();
    }
}
(note: from memory.. may not be perfect.. can also use parent::getParentFoo(); )

Posted: Tue Jul 18, 2006 5:55 am
by jamiel
Another advantage is that you have reassurance that if you want to edit/refactor a private method, it will only affect the current class, whereas a public method you have no idea what sort of impact you could have on other parts of your application. I always start with a public and private methods, then start changing private's to protected only when I have a child which needs to make use of that function.

Posted: Tue Jul 18, 2006 10:24 am
by Luke
The benefits of OOP are really starting to stand out to me now. Thanks.

Posted: Tue Jul 18, 2006 10:44 am
by MrPotatoes
PHP4 classes are like slow C Structs. still very useful and made things still very easy to get around and code. also kept everything very nice and clean

Posted: Tue Jul 18, 2006 12:06 pm
by Luke
MrPotatoes wrote:PHP4 classes are like slow C Structs. still very useful and made things still very easy to get around and code. also kept everything very nice and clean
huh? :?

Posted: Tue Jul 18, 2006 12:49 pm
by sweatje
Jenk wrote:private is the 'best' to use, and then ensure for any property you wish to change, create a setter (and getter where necessary) method.

protected I only use in abstract classes, or classes I design with the intention of them being extended.. though a fair few times, I create a protected 'parental' getter instead and maintain the private declaration.
I am nearly the opposite. I rarely find it necessary to make a method or attirbute private, but do regularly use protected to keep them out of the public API for the class. I find private as crippling as the broken "final" directive which I have never found a use for.

A question for private/final users: what makes you so sure you have written the "final" implementation and you will never want to have the potential to extend it in the future?

Posted: Tue Jul 18, 2006 1:26 pm
by timvw
I do see a reason to have private members: Nobody should care about my 'black box' implementation... Only the public interface should matter... (From this POV protected for properties is unwanted.. since it exposes things noone should know)

I do see the case against final.. And i could perfectly live without the modifier: If i want to enforce a method to remain unchanged (i make it private) and noone else can access it anyway ;)

Posted: Tue Jul 18, 2006 1:39 pm
by Luke
sweatje wrote:A question for private/final users: what makes you so sure you have written the "final" implementation and you will never want to have the potential to extend it in the future?
I asked myself that same question upon reading about that.

Posted: Tue Jul 18, 2006 2:22 pm
by Jenk
sweatje wrote:
Jenk wrote:private is the 'best' to use, and then ensure for any property you wish to change, create a setter (and getter where necessary) method.

protected I only use in abstract classes, or classes I design with the intention of them being extended.. though a fair few times, I create a protected 'parental' getter instead and maintain the private declaration.
I am nearly the opposite. I rarely find it necessary to make a method or attirbute private, but do regularly use protected to keep them out of the public API for the class. I find private as crippling as the broken "final" directive which I have never found a use for.

A question for private/final users: what makes you so sure you have written the "final" implementation and you will never want to have the potential to extend it in the future?
I don't use private methods, only properties.

_ANY_ property in a class is to be set via a setter, and 'get' through a getter imo.

Including from child to parent.

And if in later life you are going to extend, well.. you will have the original class, else you can't extend it :p

Posted: Tue Jul 18, 2006 3:10 pm
by Roja
Jenk wrote:_ANY_ property in a class is to be set via a setter, and 'get' through a getter imo.
A quite delicious response was written by someone else to that very concept.
A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.

Posted: Tue Jul 18, 2006 3:18 pm
by Luke
I agree with Roja on this one. getters and setters are a conundrum. They are meant to encapsulate, but really all it does is allow access from outside the class. (therefor defeating the purpose)