Using my earlier "shape" interface example, let's say we have a Square class that implements Shape. I can instantiate a Square object and pass it to a decorator that accepts any Shape object. How will my decorator know if the shape has magic methods? It would technically be unsafe to use the object in a way not supported by the interface. This means all getters and setters would have be defined as methods, leaving little use for the magic methods except as proxies to the real getters and setters.
-Hector
On Thu, Jun 4, 2009 at 3:05 PM, Ed Lazor <edlazor@internetarchitects.biz> wrote:
> It seems that in terms of interfaces, magic getters/setters provide no clearYou wouldn't define magic methods for interfaces. Think in terms of
> indication as to what the getters and setters are, resulting in an unclear
> API.
> Therefore, if the interface needs all of the getters/setters to be
> implemented in the classes that implement the interface, what use do the
> magic methods provide besides saving a few keystrokes?
templates. When you create an interface, you're defining a template
that will be applied to every model that implements it. The template
just gives you a list methods and the implementing class is required
to fill in the details of each method. That's why specifying magic
methods in an interface would create ambiguity; there's no way for
the implementing class to know which methods it's supposed to define.
If it helps, you can also think of an interface as a list of
requirements to be fulfilled by the implementing class.
You can add magic methods to models. You'll still end up with the
confusion of knowing whether or not an object supports different
properties. Matthew listed some benefits earlier in the thread.
Another benefit I was thinking of, you can add a field to a table in
the database and immediately start using it without having to update
your models and you can go back later to add business logic if you
need to.
Does that help?
-Ed
没有评论:
发表评论