Page 1 of 7
oop question
Posted: Sun May 17, 2009 7:48 am
by jazz090
when i first got into oop i was thrown of by all these private, public, protected, final etc... becuase i didnt see the point of having them. take the private keyword for example. it is meant to keep the variable inside a class so it cant be changed or accessed from outside. Here is my question, if you dont want it to change then dont chnage it why do you need to specify a keyword for it becuase if you dont want to to change it chances are no where in your code it specifies to do otherwise so why do you need this keyword? same again with constants and finals if you decalare a class final then it cant be extened. but if you have decalred it final, you dont want it to be extended so you havent coded to extend it anyway so why the hell do you need it if you are never gonna extended it? im sorry if this sounds stupid but it doesnt make any sense.
Re: oop question
Posted: Sun May 17, 2009 9:36 am
by Benjamin

Moved to PHP Theory and Design
Re: oop question
Posted: Sun May 17, 2009 11:25 am
by Yossarian
You can mark properties as Private or Protected so that nobody accidentally, or purposely accesses or changes them directly without you having written an accessor.
Code: Select all
class BasicMoneyClass {
protected $cost ;
function getCost( Country $country ){
( $this->cost gets formatted to the rules supplied by a Country
maybe it also checks to see the exchange rate has been set )
return $formatted_costs ;
}
}
Take this simple example where a product has a basic cost, that cost can not and should never be made public because it kept and stored as a cents value, let say.
You want to make sure that nobody anywhere can get that cost (let 's say it is $10.00) because they might just get the value out and bang a dollar sign on the cents, making it $1000, and your employer consequently loses business and maybe someone loses their job for making such a stupid mistake.
So in this case you are insuring against a known fallibility.
Re: oop question
Posted: Sun May 17, 2009 12:26 pm
by crazycoders
In addition to previous poster, note that object accessors are use with code that goes public. If you code objects for yourself, and only yourself and you know how to use your code, indeed, private and protected seems useless. When publicising code to the web so that others may use it, it is much more professionnal to limit the input/ouput of your class using them!
Re: oop question
Posted: Sun May 17, 2009 5:25 pm
by jazz090
yes i figured that like 2 minutes after posting this but i thought might get more conveneint answers.
Re: oop question
Posted: Sun May 17, 2009 5:46 pm
by Christopher
crazycoders wrote:If you code objects for yourself, and only yourself and you know how to use your code, indeed, private and protected seems useless.
I think you need to be careful about that attitude. Modern programming, from Structured Programming forward, is all about limiting unintended side-effects. Specifying private, protected or public is explicitly stating how a property can be used. You should answer that question every time you implement a property -- it's not that difficult a question. If you are not sure then use the most restrictive one possible. Then if you try to access a property in a less restricted way, you will get a nice message telling you what is going on. Then you can make an explicit decision whether to allow less restricted access or provide access in another way.
Remember, the point of functions and classes is to limit access from the outside their scope. Finer grained control just adds to your toolbox.
Those are all good things, utterly simple to do a general practice, and have proven benefits.
Re: oop question
Posted: Sun May 17, 2009 5:55 pm
by Eran
Adding to what Arborint wrote, the visibility keywords (public, protected, private) are all about declaring scope. OOP at it's most basic level is another level of scoping above functions. Functions have their own private scope and classes can group functions (methods) together, creating another level of scoping. Objects have a shared scope (called $this in PHP), which all class methods share and can use to transfer data between them and affect the object's state.
So basically the visibility keywords determine variable scope - is it just this class? is it this class and extending classes? is it public? - as arborint put it, it's just finer grained control, which can be useful when you need it to manage complexity in your application.
Re: oop question
Posted: Sun May 17, 2009 8:58 pm
by Jenk
My response to the reasons for making things protected/private is officially "meh."
If someone wants to shoot themselves in the foot, be my guest. Restricting scope only ever causes problems. If it's a show of intention, then use a comment.
Re: oop question
Posted: Sun May 17, 2009 9:55 pm
by Christopher
Jenk wrote:Restricting scope only ever causes problems.
I just want to be on record as totally, emphatically disagreeing with this statement ...
Re: oop question
Posted: Mon May 18, 2009 4:13 am
by Eran
I just want to be on record as totally, emphatically disagreeing with this statement ...
Same here...
Re: oop question
Posted: Mon May 18, 2009 8:00 am
by Jenk
arborint wrote:Jenk wrote:Restricting scope only ever causes problems.
I just want to be on record as totally, emphatically disagreeing with this statement ...
Why not enlighten me then? Can you really provide an example that will rebuke my statement?
Re: oop question
Posted: Mon May 18, 2009 12:42 pm
by Christopher
Jenk wrote:Why not enlighten me then? Can you really provide an example that will rebuke my statement?
Making a variable a class property rather than in the global scope or as a local variable rather than a property, prevents other code from unintentionally changing the value. I certainly in the past have had problems with variables in a broader scope being changed and it being difficult to track down the unrelated code that was causing the problem. Even worse is when the other code is using different assumptions and neither code will work together. That means recoding. For class properties, I have had the same problems of changing something that I should not in a library class and causing a deeper, difficult to find breakage.
Because controlling scope, which I am sure you do as well, is a structural thing -- one of the main benefits is being able to focus on a section of code free from having to think about side effects.
Re: oop question
Posted: Tue May 19, 2009 4:47 am
by jazz090
i guess at the end of the day depends who your are coding for, ive been coding for myself so i really dont see the need. even so, if you think about it, if you are coding for your self and you are making something protected or whatever, the fact that you are making it protected means your probably never gonna code to state otherwise (becuase wha would be the point is just gonna be fatal error) unless you have a lot of simmilar code with same names and your coding something like the engines that runs this forum, then again if you are doing that chances are you are working as a group.
Re: oop question
Posted: Tue May 19, 2009 5:58 am
by Jenk
arborint wrote:Jenk wrote:Why not enlighten me then? Can you really provide an example that will rebuke my statement?
Making a variable a class property rather than in the global scope or as a local variable rather than a property, prevents other code from unintentionally changing the value.
I thought we were discussing public/protected/private? I didn't see anything mentioned about global vs encapsulated.
To answer the private/protected: A decent comment/documentation does this much better, because it doesn't have the insult (loose definition of the word) of restricting it when/if the need to access it becomes necessary.
I certainly in the past have had problems with variables in a broader scope being changed and it being difficult to track down the unrelated code that was causing the problem. Even worse is when the other code is using different assumptions and neither code will work together. That means recoding. For class properties, I have had the same problems of changing something that I should not in a library class and causing a deeper, difficult to find breakage.
Because controlling scope, which I am sure you do as well, is a structural thing -- one of the main benefits is being able to focus on a section of code free from having to think about side effects.
I disagree. You don't need to have "private" just to be able to code confidently without side-effects. Just because it's "public" doesn't mean it'll instantly get used. A comment describing the member variable/method and its purpose will suffice. Honestly, what you've described is borderline paranoid programming.
Re: oop question
Posted: Tue May 19, 2009 6:39 am
by onion2k
I'll let those of you who aren't really seeing the point of public, private, protected etc into a secret about object oriented programming: OOP is for teams.
If you write code on your own then yeah, those things will seem a bit pointless. However, as soon as there's a few people writing code in the same project you
need them. Here's a small example.
Code: Select all
class Player() {
private $points;
public function getPoints() {
return $this->points;
}
public function setPoints($points) {
$this->points = abs($points);
}
}
In this example "points"
has to positive value. If it wasn't a private variable then someone else in the team could do;
That might break things (which would be caught by your unit tests, but still). The point is you don't know what stupid things people are going to try to do so you need to write code that makes it impossible to get it wrong.