You have to look at it in context.  The article is providing a general
rule of thumb for good object-oriented development, as evidenced by the
very general code snippet representing a dog and it's tail.

> This is known as a "Train Wreck". It said that this was bad because this one
> line depends on the interfaces and implied structure of three different
> objects.

Not to get technical, but the 'badness' has more to do with the fact
that the calling object is explicitly associating itself with an object
(tail) that it does not need to know about.

The point is that instead of the calling object being aware of the
dog's tail object, the caller simply tells the dog to be happy, and the
dog automatically knows what to do with it's own tail (as in the
example dog.expressHappiness()).  This, of course, represents
encapsulation.

When dealing with models in a controller, however, it gets a little bit
different.  Let's take the example of the Post model, (with
corresponding controller) which hasMany Comment.  The reason why it's
more acceptable to access $this->Post->Comment in the controller is
because while it could still be argued that Post encapsulates Comment,
it would be more accurate to say that this syntax is a reflection of
the actual relationship between the two objects (hasMany/belongsTo).

You also have to consider this within the context of the MVC
architecture, where the controller tier represents the "glue" code; the
rubber-meets-road business logic of the application.  If it can't be
abstracted, extracted or refactored, chances are it belongs in the
controller.  That being the case, it's a little bit more acceptable for
a controller to access things that aren't right in front of it's face.

Also, since PostsController is the object that effectively wraps access
to the Post model to the outside world, it's probably okay that it is
aware of the relationship of Post to other models, particularly
considering that it might well have to manipulate Comment data which is
fetched as part of a call to Post.

Since Cake already abstracts most of the busy-work out of your
application, you are free to choose the encapsulation method that fits
your situation (or fancy) the best, since they're all pretty much
equally inconsequential in terms of effort required.  In this
situation, you could:

(a) Access Comment directly, as in $this->Post->Comment->findAll
(b) Create an accessor method within Post, as in
$this->Post->getComments
(c) Use requestAction to make a call to CommentsController
(d) Use $uses to make Comment directly available, although this is
probably the least MVC-like

Hope that helps.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake 
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply via email to