On Fri, Apr 18, 2008 at 12:50 PM, Jim Lucas <[EMAIL PROTECTED]> 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
