Atomic Spin :: Elements of Software

For my last Rails project, we went to a completely Ajax interface for everything. This meant that nearly every action on a controller would result in several lines of RJS calls, along with the logic of which partial to render depending on the state of updating or creating an object.

All that logic and RJS stuff was a pain to test in a controller spec, because so much setup is needed every time you call a controller action in a test (authentication, session, etc). Any branching you have in a controller action really becomes a nuisance to test, and when the customer wants to be able to change what happens on the page when a user saves some object, rewriting those tests and the controller are even less fun.

So we came up with the idea of moving all the presentation related logic out of the controller and into helper objects we call announcers. The purpose of an announcer is to make the actual rendering calls, based on state that is passed to it by the controller.

A software developer by the name of Gustavo Duarte wrote something quite fascinating last month on Reality-Driven Development. Apparently, his writing drew many Slashdot readers to his humble blog.

In his post, Duarte draws from such disparate sources and ideas as physicist Richard Feynman’s thoughts on the Challenger disaster, natural selection, a linux discussion thread, the book Built to Last, and others to make his case for what he calls Reality-Driven Development.

Duarte says that “reality is invited in via experiments” and defines Reality-Driven Development thusly:

A good software development process should optimize experimentation and improve feedback from reality. This is what I mean by reality-driven development. And in software the most important realities are user experience and technical quality, while the primary experiments are working software and code.

He criticizes big up-front design:

And rigid upfront design is a sure way to a crappy code base or engineering disasters. Alistair Cockburn put it best: “With design I can think very fast, but my thinking is full of little holes.”

He also casts Agile development techniques in an interesting light:

There is no specific reality-driven methodology. The Agile principles have a lot in common with these ideas (and certainly influenced them), but the devil is in the details. I prefer to think of software engineering in terms of a toolbox, full of techniques we pick and choose for the right situation. Process tools for optimizing experimentation include iterative development, executable architecture, continuous integration, and unit testing.

It’s difficult to summarize all the juicy todbits. Reading the entire post is well worth the time.

I recently got an email asking when and where to instantiate MVP triads (and supporting objects) that appear in response to events in the system, but are not to be built at application start time. MDI (multiple document interface) applications are a good illustration of this: when your application starts, you have zero document editors, but as the user opens documents, you will have several editors. Who builds these transient triads?

The Question:

Hi,

... I am writing and application that consists of a Navigation pane which is a TreeView and a pane to display what has been clicked on in the navigator in tab form using a TabControl. I currently have the following triads

NavigatorModel, NavigatorPresenter, NavigatorView TabViewerModel, TabViewerPresenter, TabViewerView Type1Model, Type1Presenter, Type1View Type2Model, Type2Presenter, Type2View

Type1 & Type2 are different types of content that are to be displayed in the TabViewer. I am a bit confused now on where the Type1 & Type2 triads should be instantiated.

... Thanks for your time

Gavin

The Response:

Hi Gavin,

I would probably have a Factory object of some kind composed into the TabViewerModel. It could take some symbolic indicator of which type of thing you need to instantiate and view (Type1 or Type2), and perhaps the fundamental data needed to configure the newly created triad. The Factory then instantiates the requisite model, view, presenter (and any other supporting objects you may need in that little cluster)... then return a tuple containing a reference to both the new Model and View instance.

You need the View instance, obviously, because you’ve got to plug it into the tab view pane, or whatever. You might transfer this from the TabViewerModel through the TabViewerPresenter.

We’ve often needed to retain a reference to the Model in order to communicate with this newly created arm of the application… your needs or design may work differently. In this scenario, the new Model would wither be kept directly by the TabViewerModel, or TabViewerModel might pass it off to some sort of collection manager elsewhere in your system.

We tend to use dependency injection systems like Spring and Spring.NET (DIY for Ruby) to describe our object systems. For the overall system, we have a “main context” that would, in your case, describe the composition of Navigator* and TabViewer*, and also the TypeFactory instance.

Then, we create “sub contexts” to describe Type1 and Type2 MVP triads. The TypeFactory object would use the Spring library to load up a sub context from an XML file dedicated to, say, the Type1 triad.

The Factory approach is probably a better approach than burdening your presenters with the chore of multi-object instantiation and composition. (An alternate approach might be: compose the Factory object into the Presenter…)

One parting tip: Object instantiation, though very small in code, is a serious responsibility for an object to undertake, so don’t feel bad about spending a little extra time and effort to do it right.

Hope this helps! /Dave

As mentioned in a previous post, we’re talking more and more internally about user interface and user interaction design. Just came across an interesting resource: the User Interface Design Pattern Library.

Today I got an email from Sandro Aloisio asking an important question about the connection of one MVP triad to another. When introducing the basics of Presenter First, one usually runs out of breath before getting to the topic of connecting triads using Managers (or Coordinators, whatever you call them), which is a technique that has grown up a little and proven to have some merit. So here’s a little more discussion on that front:

Q: There should be at least one MVP triad per user story, is that correct?

Yes, at least one triad for a user story is a good way to go, especially at the outset of a project. It’s worth pointing this out, as I have seen code written by folks who interpret Model-View-Controller patterns to mean your application should consist of exactly 3 gigantic classes.
One user story usually involves one or more like-minded statements that start with “when the user clicks Save” and “when the user clicks Cancel”. A subsequent user story might augment a feature by saying “when the user clicks Apply, save changes but don’t dismiss the dialog” which might involve going back to the old Presenter for that feature.

And it could happen that a small handful of innocent, related phrases from the same story are technically separated enough to make you want to compose more than one triad to answer the story. There’s nothing in the pattern (or our experience) that says this is a problem. At worst, you’ve added a little extra interface code. At least you’ve introduced that much more domain language into your code.

That second case comes up often when the actual verbiage from the customer covers a lot of ground, such as “I can double-click the user name in the list, change that user’s password, then save.” This implies a collection of smaller stories, such as an interactive user list, a password editor, etc. Decomposing the larger story into several related smaller stories gets you several related MVP triads which will need to interact according to the overall user story.

Q: What if a model from one MVP needs to know the state of a foreign model (in another MVP)?

The model-to-model communication you’re asking about is something we answer with the loosely-named “manager” pattern (naming of these objects varies from project to project, I’ll discuss that below). A Manager is structurally identical to a Presenter: it acts as an observer on two objects, and channels data and intentions from one to the other. The Manager exists only to do these things, and has no public API (same as Presenter) and nobody holds a direct reference to this object.

Managers come into existence when you recognize that a user story describes the interaction between two other story-level application features. You’ve already got a triad for each feature, and you’ve decided that the models from these features need to talk to each other. Responsibility and testability issues pop up quickly if you simply let the models reference one another directly, and even if you try to wire one model up to observe the other. (We’ve found that subscribing for, reacting to and processing input is indeed too much to do cleanly all in one class… Presenters lift a lot of this burden from our backs.)

A Presenter’s basic event-and-data brokering habits have freed you up to write much simplified View and Model code. Objects get to “wish” for things to make their testing easier, like “I wish someone would send this data to me, instead of my having to retrieve it, and knowing when”. if you take two models and put a Presenter-ish object between them (creating a new triad) you get to connect your models without overloading them too much. Additionally, you’ve got a specific place to transcribe the user story that connects these two features in the first place.

If you still feel like your models in this triad are starting to get somewhat heavy in their dual responsibilities, do not hesitate to elaborate on the relationship between the models by introducing more models, and perhaps more Managers to connect them. Don’t be frightened of the additional classes… if a problem has become complex enough to make you ask yourself if you need another class to get the job done, you probably do.

On naming:

In several large projects, we found that we wanted to reserve the word Presenter for that specific type of object that connects Models to Views (or Adapters, but that’s a different topic). Verbal design sessions are easier when the words always mean the same thing. In our seach for terms that mean “Presenter-like object that connects models to models” we’ve used Manager, Conductor and Coordinator. We tend to refer to this aspect of Presenter First as the “coordinator pattern” or “manager pattern.”

When choosing a specific name for a Manager object, try naming it directly for the feature the object will enabled. Eg, you might connect the UserListModel and PasswordEditorModel via the UserPasswordEditorCoordinator.

Brooke Hamilton has developed some of his own extensions to Presenter First and a cool-looking visual modeling tool to match. We at Atomic have not put it to use yet (none of us is using Visual Studio 2008) but it sure looks snazzy.

The tool and its source code are hosted on CodePlex: A Modeling Tool for the Presenter First Pattern

Also linked from that page is a bit of explanation regarding Brooke’s take on PF, setting it up for DSL use. I have not made use of this derivation of Presenter First (I tend to use my Presenters as the place where I describe my features—the one part of my application that cannot be auto-generated) but Brooke’s tool and approach have been working well for him, and as he says, “it’s a lot of fun, too.” Give it a read.

We’ve been talking quite a bit these days in the office about user interfaces and interaction design. I came across an interesting post on the Architectures of Control | Design with Intent blog by Dan Lockton, a PhD researcher at Brunel University’s School of Engineering & Design.

In his post Interesting Parallels, Dan draws on unique definitions of interaction design and security (namely, that both are related to shaping human behavior) to tie the two together. He quotes a computer security specialist and interaction design expert to draw the parallel:

“Security is about preventing adverse consequences from the intentional and unwarranted actions of others. What this definition basically means is that we want people to behave in a certain way… and security is a way of ensuring that they do so.”

Bruce Schneier, Beyond Fear

“A simpler way of thinking about Interaction Designers is that they are the shapers of behavior. Interaction Designers… all attempt to understand and shape human behavior. This is the purpose of the profession: to change the way people behave.”

Jon Kolko, Thoughts on Interaction Design

It’s a rare software project that doesn’t require a developer to think about and implement user interfaces or security in some fashion. So it seems immensely useful for a software developer to view himself or herself as a shaper of human behavior, asking questions as a behaviorist to effectively create useful interfaces and secure software.

PresentationObject is an implementation of Jay Fields’ Presenter pattern in Rails. It has familiar declarative style syntax and offers encapsulating presentation logic in a testable object.

Without a presenter-like object it’s easy to spread presentation logic and information across the MVC architecture: models end up with unneeded methods, controllers make unneeded decisions and view templates become corroded by unneeded code. Combined it becomes difficult to test and maintain presentation logic in the application.

Here’s an example of a simple presentation-oriented method existing in a model:

1
2
3
4
5
6
7
8
9
10

class Group < ActiveRecord::Base
  belongs_to :parent
  has_many :subgroups

  def show_relationships?
    return true if parent || subgroups.any?
    false
  end

end

The show_relationships? method is only used in a view to determine whether or not it should display the relationships information. It doesn’t really belong on the model.

Here’s an example of a controller making presentation decisions:

1
2
3
4
5
6
7
8
9
10
11

class GroupsController < ApplicationController

  def index
    if current_user.superuser?
      @groups = Group.find(:all)
    else
      @groups = Group.find_active_groups_with_member(current_user)
    end
  end

end

The index action introduces an unneeded branch of logic for a controller to have. It is painful to see this branch sprinkled throughout any controller that has to do with supplying @groups to the view because you will have to test the branch separately for each controller action that includes it. A common mistake made is to make this branch a before filter and define the method inside of the ApplicationController. Before filters can be easily misused and that is a topic for its own post so let’s not discuss that here—just know that using a before filter for this example is not the best thing to do.

Here’s an example of code that should not be in the view:

1
2
3
4
5
6

<%= Group::GROUPS_TITLE %>
<% Group.find(:all).each do |group| %>
  <% if group.member?(@current_user) %>
    <%= link_to h(group.name), group_path(group) %>
  <% end %>
<% end %>

The first thing to stand out is the Group.find(:all) call. It shouldn’t be there. The second thing to spot is the group.member? call. It doesn’t need to be there. Lastly, the usage of the GROUPS_TITLE constant doesn’t belong in the view.

Rather then sprinkling these presentation-oriented decisions and knowledge across the whole MVC architecture the PresentationObject drops in as an intermediary between the view and the model. It is responsible for knowing that the logic it contains will be presentation logic. This makes it the perfect place to put logic that otherwise shows up in the model, controller or view. A strength of the presenter is that it can mimic the model.

Here’s a GroupPresenter moving code out of the model:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class GroupPresenter < PresentationObject
  delegate :id, :to_param, :name, :members, :to => :@group

  def initialize(options)
    @group = options.delete(:group)
  end

  declare :show_relationships? do
    return true if @group.parent || @group.subgroups.any?
    false
  end
end

# in a controller action that deals with a single group
def some_action
  group = Group.find(params[:id])
  @group = GroupPresenter.new group
end

By creating a GroupPresenter we’re able to keep our model responsible and disciplined. It also allows us to make little or no change to the view since the GroupPresenter delegates the necessary methods. Now, moving one method out may or may not be enough motivation for you to create a presenter. That depends on the situation you and your code are in. Unfortunately there’s rarely just one method that doesn’t belong on the model.

Here’s a GroupsPresenter moving code out of the controller:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class GroupsPresenter < PresentationObject
  include Enumerable

  def initialize(options={})
    @user = options.delete(:user)
  end

  declare :groups do
    if @user.superuser?
      Group.find(:all)
    else
      Group.find_active_groups_with_member(current_user)
    end
  end

  def each(&blk)
    groups.each(&blk)
  end

end


# in the index controller action
def index
  @groups = GroupsPresenter.new :user => current_user
end

Here the view won’t have to change. You gave it an array of groups before and you are giving it an object which acts exactly the same. The only difference is that your GroupsPresenter will make the right decision on what groups should be iterated over.

Before we look at a cleaned up view template there is more benefit with the PresentationObject and these last two examples.

First, it’s easily testable since all of the work is done in the methods themselves. Here’s a spec example covering the GroupPresenter we extracted from the model:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

describe GroupPresenter, 'delegates' do
  before do
    @group = mock('group')
    @presenter = GroupPresenter.new :group => @group
  end

  it_delegates :id, :to_param, :name, :members, :on => :presenter, :to => :group 
end

describe GroupPresenter, 'show_relationships?' do
  before do
    @group = mock('Group')
    @presenter = GroupPresenter.new :group => @group
  end

  describe 'when the passed in :group has a parent' do
    it 'returns true' do
      @group.should_receive(:parent).and_return(true)
      @presenter.show_relationships?.should be_true
    end
  end

  describe 'when the passed in :group does not have a parent, but has subgroups' do
    before do
      @group.stub!(:parent).and_return(nil)
    end

    it 'returns true' do
      @group.should_receive(:subgroups).and_return([:subgroup])
      @presenter.show_relationships?.should be_true
    end
  end

  describe 'when the passed in :group does not have a parent or any subgroups' do
    before do
      @group.stub!(:parent).and_return(nil)
      @group.stub!(:subgroups).and_return([])
    end

    it 'returns false' do
      @presenter.show_relationships?.should be_false
    end
  end
end

The it_delegates spec helper is included at the bottom of this post.

Secondly, the presenter uses lazy evaluation and implements caching. For example the GroupsPresenter declares a :group method which retrieves all groups the user is able to see. This can be called as many times as you want, but it will only execute the first time. Every subsequent call will return a cached result. For example:

1
2
3
4
5
6
7
8
9
10
11
12
13

groups = GroupsPresenter.new :user => current_user
groups.each { || } # this will call :groups which will make a find call to Group
groups.each { || } # this will returned the cached value from the last time :groups was called

#likewise for the GroupPresenter
group = GroupPresenter.new :group => Group.find(:first)
group.show_relationships? # executes our implementing code
group.show_relationships? # returns the cached value from the last execution</li>

# this works for delegated methods to
group = GroupPresenter.new :group => Group.find(:first)
group.to_param # executed the delegated call to our group model
group.to_param # returns the cached value from the last execution

So depending on whatever your view ends up actually displaying the minimum number of calls to the database or to complicated methods will be made.

A real-world example of this is implementing a leader board which involves users, scores, games and user play regions. In order to show the leader board a number of computationally heavy algorithms and queries have to execute. These database and CPU intense calculations should happen once. PresentationObject gives you this advantage—for free.

Another advantage that is easy to overlook is where the decision is made that determines which specific query or computation to run. When it’s in a presenter it is isolated in an object which is only concerned with doing the right thing based on what needs to be displayed to the user. This makes it much simpler to comprehend and track down when compared to housing it inside one of the alternatives: the model and the controller.

But back to cleaning up the view template. Here’s what the view template should look like:

1
2
3
4

<%= @groups.title %>
<% @groups.each do |group| %>
  <%= link_to h(group.name), group_path(group) %>
<% end %>

We’ve pulled out two important things from the view template: the GROUPS_TITLE constant and the conditional logic checking the current user for group membership.

Here’s the presenter that goes with the new view template:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class CurrentUserGroupsPresenter < PresentationObject
  include Enumerable

  def initialize(options)
    @user = options.delete(:user)
  end

  def each(&blk)
    groups.each(&blk)
  end

  declare :groups do
    Group.find_active_groups_with_member(@user)
  end

  declare :title do
    Group::GROUPS_TITLE
  end
end

# in the index controller action
def index
  @groups = CurrentUserGroupsPresenter.new :user => current_user
end

Pulling out the GROUPS_TITLE constant into a method on our presenter is important because the view template doesn’t need to know what title should be displayed. It just needs a title to display. If we wanted to build a title dynamically there is one single place where we can change that logic without affecting the view or anything else—the presenter.

Pulling out the conditional logic from the view template into our presenter gives us several advantages.

First, the view template is now available to be reused as a partial because it is only displaying the groups it is given. We can make the decision elsewhere on what groups to show and our template will just work.

Second, we’ve removed the urge to add any other conditional statements in that loop. We were just checking for group membership, but maybe we need to see if the user is a superuser. By placing this logic in the presenter we have removed the temptation of just adding more logic to the view template.

Lastly, we have created a single testable object for this presentation logic—our presenter. This greatly simplifies our view tests and the implementation of our views. And it stays consistent with placing this logic in a single object whose responsible for making these presentation-oriented decisions.

An alternative to this approach prior to the refactoring would have been to extract the code into a controller helper. This isn’t the right thing to do in our example. Helpers are too often used to tuck away code that shouldn’t be out in the presentation layer. They appear to add benefit because it’s so simple to move things from a view into a helper, but the long term debt far outweighs this short term gain. Helpers aren’t highly cohesive objects. Their responsibilities tend to be a little bit of everything and this hurts the ability to have simple testable objects that have highly cohesive behavior and responsibility. It also hurts maintainability. And it adds to the temptation that it is ok to put code in a helper that shouldn’t otherwise be there.

The name of this last presenter was CurrentUserGroupsPresenter whereas the earlier examples were GroupPresenter and GroupsPresenter. The goal of a presenter is to reduce the sprinkling of presentation logic throughout the system which in turn reduces complexity. We’ve found that presenters are cheap to create and work with. They usually work best when they focus on a single component in the UI. If we have four different components on the UI which each uniquely display groups on the site there may be four different group presenters, each one focusing on a specific UI component.

This differs from Jay Field’s presenter concept in that it focuses on encapsulating presentation logic rather then just encapsulating actions that operate on a model from the controller. This isn’t to say that these two ideas can’t be combined successfully or that one is better then the other. We have found that encapsulating presentation logic in a presenter is a great win overall and we haven’t had the need to push other responsibilities such as model creation and updates onto the presenter itself. This usually ends up in a manager-like object.

Installing PresentationObject

1
2
3
4
5

# installing the latest presentation_object (points to 0.1.0)
script/plugin install svn://rubyforge.org/var/svn/atomicobjectrb/tags/presentation_object

# installing the 0.1.0 release specifically
script/plugin install svn://rubyforge.org/var/svn/atomicobjectrb/tags/presentation_object-0.1.0

it_delegates

An RSpec helper:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

module Spec::Example::ExampleGroupMethods
  def it_delegates(*args)
    options = args.extract_options!
    methods = args
    src = options[:on]
    to = options[:to]
    raise "Missing an object to call the method on, pass in :on" unless src
    raise "Missing an object to ensure the method delegated to, pass in :to" unless to

    method_options = options.reject{|k,v| [:on, :to].include?(k)}
    methods.each {|m| method_options[m] = m}
    method_options.each do |source_method, to_method|
      it "delegates ##{source_method} to @#{to}.#{to_method}" do
        obj = instance_variable_get "@#{to}"
        _src = instance_variable_get "@#{src}"
        return_val = stub("return val")
        obj.should_receive(to_method).and_return(return_val)
        _src.send!(source_method).should == return_val
      end
    end
  end
end

About a year ago Greg Pattison and I began working together on a new C++ application for a client. It was the first C++ project of any significant size for either of us since becoming enamored with interaction-based testing techniques.

Interest in Presenter First seems to be really growing. We’ve received lots of response lately through our blog and website. No doubt, this is thanks in large part to Ron Jacobs of ARCast and his recent series of Podcasts.

Brian Harleton (one of the originators of Presenter First and an author of the Agile 2006 Presenter First paper) forwarded on a link to something very interesting he came across today:

TDD for Both Stand-alone GUI-based application And Eclipse Plug-in Development”

These case studies were conducted by Li Le and Li Meng, two students of School of Computing, Dublin City University.

“Through all the case studies we did and the experience we had to develop this plug-in, it can be proved that presenter first TDD is an excellent software development method used to develop both Stand-alone GUI-based applications and Eclipse Plug-ins.”

Ron Jacobs recently spent a morning with Dave Crosby & Scott Miller talking about Presenter First and recorded the conversation for his Podcast.

Original post

Part 1: video audio

Part 2: video audio

Part 3: video audio

Ron Jacobs recently spent a morning with Dave Crosby & Scott Miller talking about Presenter First and recorded the conversation for his Podcast.

Original post

Part 1: video audio

Part 2: video audio

Ron Jacobs recently spent a morning with Dave Crosby & Scott Miller talking about Presenter First and recorded the conversation for his Podcast (read earlier post).

The video is available on ARCast.TV. The audio is available from ARCast Radio.

Now available: The sample project we distributed on CD to complement our presentation at Embedded Systems Conference Silicon Valley 2007.

Ron Jacobs, a traveling Microsoft evangelist and host of ARCast.TV and ARCast Radio visited the Atomic Object office last week and we chatted for quite a while about TDD, MVP and Presenter First development methodologies for his podcast.