Re: PHP5 and the DOM model
| From: | Nick Stinemates | Date: | Fri, 18 Apr 2008 17:50:51 +0000 |
| Subject: | Re: PHP5 and the DOM model | ||
| References: | 1 2 3 4 5 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-273257@lists.php.net to get a copy of this message | ||
>> 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.
The general rule of encapsulation is: Don't ask an object for data, ask
the object to work with the data.
--
Nick Stinemates (nick@stinemates.org)
http://nick.stinemates.org