Re: PHP5 and the DOM model
| From: | Nick Stinemates | Date: | Fri, 18 Apr 2008 17:21:14 +0000 |
| Subject: | Re: PHP5 and the DOM model | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-273253@lists.php.net to get a copy of this message | ||
On Fri, Apr 18, 2008 at 10:25:29AM -0600, Nathan Nobbe wrote:
> On Thu, Apr 17, 2008 at 5:43 PM, Nick Stinemates <nick@stinemates.org>
> wrote:
>
> > On Thu, Apr 17, 2008 at 10:05:11AM +0200, Michael Preminger wrote:
> > > 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.)
> >
>
> 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.
>
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.
--
Nick Stinemates (nick@stinemates.org)
http://nick.stinemates.org