On Fri, 2008-04-18 at 11:50 -0700, Jim Lucas wrote:
> Nick Stinemates wrote:
> >>> Data Hiding IS Encapsulation.
> >>> But, you have to agree,
> >>> <?php
> >>> class Lol {
> >>> private $bar;
> >>> public function getBar() { return $bar }
> >>> public function setBar($bar) { $this->bar = $bar}
> >>> }
> >>> ?>
> >>> Is no different than:
> >>> <?php
> >>> class Lol {
> >>> public $bar;
> >>> }
> >>> ?>
> >>> Here's a more thought out argument from
> >>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html :
> >>>> 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.
> >>>>
> >>>> To see why, consider that there might be 1,000 calls to a getX() method
> >>>> in your program, and each call assumes that the return value is of a
> >>>> particular type. You might store getX()'s return value in a local
> >>>> variable, for example, and that variable type must match the return-value
> >>>> type. If you need to change the way the object is implemented in such a
> >>>> way that the type of X changes, you're in deep trouble.
> >> No,but in the first one, you can control, from within the class/method,
> >> what data is actually allowed to be injected into that variable. Whereas
> >> the second example would allow you to stuff any type of data into that
> >> class variable. That might not be a good thing.
> >>
> >
> > That's a relatively narrow minded response to my point, since I gave
> > a pretty concrete example of exactly what I meant, followed by a great
> > article which furthered my point.
> >
>
> Let me quote, you said this: "Is no different than" You are wrong, in fact it
> IS different. Having your own custom methods to get or set data allows you to
> have more control over what data is injected into your object.
>
> I would call is a personal preference which may not work for you, but works fine
> for me.
>
> All I can say is that all my __set methods do data sanitizing and validation,
> which is were I think it should be done. If anybody thinks this might be a bad
> thing, please by all means explain why it is bad.
>
>
> > The general rule of encapsulation is: Don't ask an object for data, ask
> > the object to work with the data.
> >
>
> I hope it checks the data first before using it. If you don't then you might
> end up with something you had not planned on.
>
> If I am not to ask an object for data how is my db class/object ever going to
> return me data from my database?
What he means is don't ask for the data literally (by property name) ask
for it via a method. This allows wrapping the data in "work". This is a
moot issue in PHP since PHP allows trapping the property accessor.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
