>> 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@xxxxxxxxxxxxxx) http://nick.stinemates.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php