public, private, and protected
Posted: Mon Jul 17, 2006 10:01 pm
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?
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
it should be the same as in C++. i dunno protected because i never used it. like friends, blehThe 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?
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
?>Code: Select all
abstract class Parent
{
private $foo;
protected function getParentFoo ()
{
return $this->foo;
}
}
class Child extends Parent
{
public function getFoo ()
{
return $this->getParentFoo();
}
}huh?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
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.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 asked myself that same question upon reading about that.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 don't use private methods, only properties.sweatje wrote: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.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.
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?
A quite delicious response was written by someone else to that very concept.Jenk wrote:_ANY_ property in a class is to be set via a setter, and 'get' through a getter imo.
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.