public, private, and protected
Moderator: General Moderators
public, private, and protected
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?
- MrPotatoes
- Forum Regular
- Posts: 617
- Joined: Wed May 24, 2006 6:42 am
Re: public, private, and protected
--------------------------------------------------------------------------
[edit] dude, i'm the pwn. i was right
--------------------------------------------------------------------------
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
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?
[edit] dude, i'm the pwn. i was right
--------------------------------------------------------------------------
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?
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
?>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?
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.
(note: from memory.. may not be perfect.. can also use parent::getParentFoo(); )
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();
}
}-
jamiel
- Forum Contributor
- Posts: 276
- Joined: Wed Feb 22, 2006 5:17 am
- Location: London, United Kingdom
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.
- MrPotatoes
- Forum Regular
- Posts: 617
- Joined: Wed May 24, 2006 6:42 am
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?
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
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
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?
_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
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.