Hi,
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.
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
>
没有评论:
发表评论