Categorized | News, OOP

Class Naming Should Clearly define Object Responsibility

Posted on 27 May 2007 by Demian Turner

Rendering views just got a whole lot easier with the Zend framework 😉 If don’t yet have a front controller instance:

$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view); 

or if you do:

$viewRenderer = Zend_Controller_Action_HelperBroker::getExistingHelper('viewRenderer');

Okay, maybe it’s not that easy. Let’s look at how the $viewRenderer object is instantiated, using the Zend_Controller_Action_Helper_ViewRenderer class. Using the PEAR naming convention has proven its worth beyond the point of contest, but how many related concepts are inferred by this class name?

Bookmark and Share

2 Comments For This Post

  1. Matthew Weier O'Phinney Says:

    I appreciate the criticism, really, I do. But I also think that you’re taking the name completely out of context.

    The new component is what’s called an ‘Action Helper’, and is analogous to the ‘View Helpers’ we’ve had available in ZF since the initial release. The idea is that action helpers provide ways to extend the functionality of action controllers without needing to extend the base action controller class. In essence, it’s a Plugin or Broker pattern; we did not name it a Plugin, however, due to the existence of Zend_Controller_Plugin (which connects to the front controller), as well as the aforementioned analogous view helpers. (It’s also a Factory, as it handles instantiation on-demand.)

    So, we have a HelperBroker to manage on-demand loading (Factory), as well as to act as a Registry of sorts (to allow registering specific objects with the broker, as well as keeping helper object instances alive between controller instances; hence the singleton). As mentioned, these are to enhance the action controllers, and thus the ‘Zend_Controller_Action’ namespace.

    Yes, the naming conventions lead to hugely long names. I hate that, personally — but until we have namespaces in PHP, it’s an unfortunate necessity.

    Next, you note “look at how a view renderer is created once a front controller exists.” This is entirely out of context.

    First off, the ViewRenderer is instantiated and registered with the action helper broker when the front controller is instantiated. The method you quote is so that you can retrieve the existing instance and modify it after the fact.

    Second, in most cases you’ll *never* need to perform that particular action. In the default use case, the one most developers will use, you would never need to fetch the ViewRenderer nor even think about it. You end up using it, but it’s entirely in the background. The main thing you’ll note, if you started using ZF early, is that you get to code less. Ironic, eh, since the class name for the ViewRenderer is so long…

    When you do need to access the ViewRenderer, in most cases it will be from your individual action controllers. In those cases, you already have direct access to the broker as it is registered as a class property:

    [geshi lang=php]
    // Get the view renderer object:
    $viewRenderer = $this->_helper->getHelper(‘viewRenderer’);

    // Or access it directly as a property of the broker:

    You also ask, “presumably two linked concerns are going to be decoupled, but where are remote services being invoked in the view rendering?” In this case, a decision was made to keep the controller and view functionalities decoupled; the ViewRenderer gives action controllers access to the view object, plain and simple.

    As noted previously, I very much dislike the long names I’m forced to create for ZF — I have to type them day-in and day-out, and it’s painful. However, I also truly believe in meaningful names; shorthand or truncated names lead to confusion. So, here’s my question to you: how would you name a view helper for action controllers?

  2. Demian Turner Says:

    Hi Matt

    i was going to write a detailed response to your comment then realized I already did, in a 2005 article you can find here:

    Curious what you think of this solution, borrowed largely from Matt Zandstra’s ‘Objects, Patterns & Practice’ book, an excellent resource. In my view this is a lot less code and consequently more elegant solution. Class names are shorter mainly because I don’t think Actions need to be grouped in Controller class family – again this follows Zandstra’s ideas. Also I think it’s quite confusing to refer to anything related to a plugin as a ‘broker’ – broker has a very specific (and different) meaning in the wider/java context.

Leave a Reply



Demian Turner's currently-reading book recommendations, reviews, favorite quotes, book clubs, book trivia, book lists



PHPkitchen recommends you also check out the following sites :

Accounting for Small Businesses

FreeAgent sign-up