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