Re: PHP5 and the DOM model
| From: | Jim Lucas | Date: | Fri, 18 Apr 2008 17:35:59 +0000 |
| Subject: | Re: PHP5 and the DOM model | ||
| References: | 1 2 3 4 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-273256@lists.php.net to get a copy of this message | ||
Nick Stinemates wrote:
On Fri, Apr 18, 2008 at 10:25:29AM -0600, Nathan Nobbe wrote: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. -- Jim Lucas "Some men are born to greatness, some achieve greatness, and some have greatness thrust upon them." Twelfth Night, Act II, Scene V by William ShakespeareOn Thu, Apr 17, 2008 at 5:43 PM, Nick Stinemates <nick@stinemates.org> 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 :On Thu, Apr 17, 2008 at 10:05:11AM +0200, Michael Preminger wrote:egh? we had a massive argument about this last year, but if u ask me data hiding is an integral part of encapsulation; therefore i agree w/ Michael.Hello! Seems that PHP gets more and more object oriented, which is good. I am now running a course in PHP, using PHP 5, where we are going to use the *DOM* interface. I am trying to teach them good OO practices, meaning that we insistently hide properties and expose them as get or set methods.Get/set methods are more often than not breaking encapsulation and should be avoided (unless purposefully designing Model object or something similar.)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.