(on Wednesday, 03 June 2009, 11:16 AM -0700):
> Using __get() and __set() for properties known at the time of writing is a
> minor time saver for you, the programmer, and can be a major time waster for
> those trying to debug or otherwise understand your code. It's a bad practice.
I disagree, and feel it's a documentation issue.
Doing so can often make a class forward-compatible with future versions
by ensuring uniform accessors and properties tied to accessors from the
start. You may not need them immediately, but you may in future
iterations, and adding them later would be a BC break and/or require
adding __set and __get anyways, but now with more complex logic.
> On Wed, Jun 3, 2009 at 8:23 AM, Ed Lazor <edlazor@internetarchitects.biz>
> wrote:
>
> > Userland code -- code built on top of the framework -- has fewer
> > restrictions in this regard, and I often find myself using public
> > properties in such situations. I just find it hard to justify them
> > within development of the framework itself.
>
> When you find yourself using public properties, is that just a matter
> of convenience or is there some sort of benefit? For example, are you
> trying to save the overhead of calling a method?
>
> Do you draw a distinction between personal code and professional
> (non-ZF) code when using accessors?
>
> So far, it seems like I should just be using magic methods to create
> accessors, use them in my code so I don't have to search my code for
> changes if I decide to wrap a property in business logic, define
> non-magic methods when I want to add business logic, and minimize the
> need for accessors by assigning as much responsibility to objects as
> possible. Does that sound like the best approach for code that I
> would be creating for others in a professional capacity?
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
没有评论:
发表评论