Re: PHP5 and the DOM model

On Fri, Apr 18, 2008 at 12:50 PM, Jim Lucas <lists@cmsws.com> wrote: > > 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. > lol. wait a second, jim, you think a class w/ 2 methods isnt the same as one w/ no methods :O I would call is a personal preference which may not work for you, but works > fine for me. strangely enough, last year when we argued, it became clear the definition of encapsulation varies quite a bit across the people who subscribe to this list, tho i posted 4 examples from texts ive read over the years that all essentialY incorporate data hiding into the definition of encapsulation. 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. > right; 100%. and even if setters are as simple as function setStuff($stuff) { $this->stuff = $stuff; } the client is still being driven through a well defined public interface, which supports the ability to add validation logic later on w/o impacting client code. you could also change the internal variable from $stuff to $goofy and it would be transparent to the client. the point here is indirection, which in programming terms is basically synonymous w/ flexibility. yes there are costs, runtime performance, system complexity, but these are the tradeoffs for flexibility. when you take it to a higher level thats what design patterns are all about. standardized techniques to incorporate flexibility into an application. -nathan