(on Tuesday, 02 June 2009, 11:53 AM +0200):
> Personnally I agree with Matthew, in php setters are very useful for
> checking variable types. => very easy rule of thumbs: if you need a
> variable to be of a certain type, use setter otherwise don't.
>
> Regarding to getters, well if you used setters then you will need
> getters, and vice versa.
>
> I'm not sure it would be good to implement a full 'no setters/getters'
> policy, neither a full 'setters/getters only' policy but instead a mix
> of these (as highlighted in the article).
>
> How is ZF usage on this? With each new version of ZF, I have the
> 'feeling' that it goes more towards a full 'getter/setter' policy
> which may not always be optimum.
ZF is quite different than userland code, however. Users of ZF
components need to know what properties are available, what types they
may be, and how to access them -- and also that they are well-tested.
Public properties definitely have their place. However, it is difficult
for ZF to use them internally and still achieve the goals as outlined.
Getters and setters are easy to test, and make it easy to insulate
end-users from changes in implementation.
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.
> I don't think there's a yes/no answer to this. My advice is not to use
> getters and setters by default, and implement them only when you do
> feel the need for it (like when type-checking is crucial or data needs
> to be formated/parsed when set).
> Remy
>
> On Mon, Jun 1, 2009 at 4:14 PM, Ed Lazor <edlazor@internetarchitects.biz>
> wrote:
>
> Hi =)
>
> Hope Everyone had a good weekend. No response to the last message
> that I sent, so I figured I'd follow-up this morning. What do you
> think of the approach described below? Can it lead to unexpected
> problems? Are we using the same approach that you use? In
> particular, I'd really like some feedback - what's your opinion on
> using the magic accessors? Its been a little bit of a debate amongst
> our team - one side arguing that we should be sticking with the use of
> get and set accessors and the other side arguing that magic accessors
> does the same thing while saving you from having to actually type
> "get" and "set" everywhere.
>
> -Ed
>
>
>
>
> On Fri, May 29, 2009 at 5:05 PM, Ed Lazor<edlazor@internetarchitects.biz>
> wrote:
> >> All of this said... when possible, and where it makes sense, I like to
> >> use direct property access. You just have to test carefully to ensure
> >> that common use cases will not break the functionality of the class.
> >
> > What happens later on when you need to add business logic to something
> > you've been accessing directly? Do you end up having to refactor a
> > lot of code?
> >
> > Our team ended up using this:
> >
> > class SourceRow extends Zend_Db_Table_Row_Abstract {
> > public function __get($key) {
> > if(method_exists($this, $key)) {
> > return $this->$key();
> > }
> > return parent::__get($key);
> > }
> > }
> >
> > It saves having to prepend everything with get.
> >
> > All of our models extend SourceRow. We end up creating a method with
> > a name matching that of the property, if we want to override the
> > property and introduce business logic. Of course, then the question
> > is, how do you access the value of the property? Our solution, so
> > far:
> >
> > public function isComplete() {
> > // insert business logic here
> > return Zend_Db_Table_Row_Abstract::__get("IsComplete");
> > }
> >
> > Is that a very good solution though? Does this cause problems
> > anywhere? It seems like this wouldn't even be an issue if we were
> > using accessors.
> >
> > It seems, IMHO, that we should just always use accessors. We could
> > use magic methods to save having to actually create the methods unless
> > we add one to insert business logic. It creates a common interface -
> > so we don't have to try and figure out which approach you're supposed
> > to use when working with models created by someone else on your team.
> > Plus, it would save having to rewrite code if you change something.
> >
> > If I do that though... I end up promoting the idea that accessors
> > should always be used - sounds like this isn't what everyone else is
> > doing.
> >
> > Thoughts?
> >
> > -Ed
> >
>
>
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
没有评论:
发表评论