TITLE: The Special Case Object Pattern in "Confident Ruby"
AUTHOR: Eugene Wallingford
DATE: April 21, 2014 2:45 PM
DESC:
-----
BODY:
I haven't had a chance to pick up a copy of
Avdi Grimm's
new book,
Confident Ruby,
yet. I did buzz by the book's
Pragmatic Programmers page,
where I was able to pick up a sample chapter or two for
elliptical reading.
The chapter "Represent special cases as objects" was my first
look. This chapter and the "Represent do-nothing cases as
null objects" chapter that follows deal with situations in
which our program is missing a kind of object. The result is
code that has too many responsibilities because there is no
object charged with handling them.
The chapter on do-nothing cases is @avdi's re-telling of the
Null Object pattern. Bobby Woolf workshopped
his seminal write-up
of this pattern at
PLoP 1996
(the first patterns conference I attended) and later published
an improved version in
the fourth Pattern Languages of Program Design book.
I had the great pleasure to correspond with Bobby as he
wrote his original paper and to share a few ideas about
the pattern.
@avdi's special cases chapter is a great addition to the
literature. It shows several different ways in which our
code can call out for a special case object in place of a
null reference. It then shows how creating a new
kind of object can make our code better in each case,
giving concrete examples written in Ruby, in the context
of processing input to a web app.
I was discussing the pattern and the chapter with a student,
who asked a question about this example:
if current_user
render_logout_button
else
render_login_button
end
This is the only example in which the if
check is not eliminated after introducing the special case
object, an instance of the new class, GuestUser.
Instead, @avdi adds an authenticated? to the
User and GuestUser classes, has them
return true and false respectively, and
then changes the original expression to:
if current_user.authenticated?
render_logout_button
else
render_login_button
end
As the chapter tells us, using the authenticated?
predicate makes the conditional statement express the
programmer's intent more clearly. But it also says that "we
can't get rid of the conditional". My student asked, "Why
not?"
Of course we can. The question is whether we want to. (I
have a hard time using words like "cannot", "never", and
"always", because I can usually imagine an exception to the
absolute...)
In this case, there is a lingering smell in the code that
uses the special case object: authenticated? is a
surrogate for type check. Indeed, it behaves just like a
query to find the object's class so that we can tailor our
behavior to receiver's type. That's just the sort of thing
we don't have to do in an OO program.
The standard remedy for this code smell is to push the
behavior into the classes and send the object, whatever its
type, a message. Rather ask a user if it is authenticated
so that we can render the correct button, we might ask it
to render the correct button itself:
current_user.render_button
...
class User
def render_button
render_logout_button
end
end
class GuestUser
def render_button
render_login_button
end
end
Unfortunately, it's not quite this simple. The
render_logXXX_button methods don't live in the
user classes, so the render_button methods need
to send those messages to some other object. If the user
object already knows to whom to send it, great. If not,
then the send of the render_button message will
need to send itself as an argument along with the message,
so that the receiver can send the appropriate message back.
Either of these approaches requires us to let some knowledge
from the original context leak into our User and
GuestUser classes, and that creates a new form of
coupling. Ideally, there will be a way to mitigate this
coupling in the form of some other shared association. Ruby
web developers know the answer to this better than I.
In any case, this may be what @avdi means when he says that
we can't get rid of the if check.
Doing so may create more downside than upside.
This turned into a great opportunity to discuss design with
my student. Design is about trade-offs. Things never seem
quite as simple in the trenches as they do when we learn
the rules and heuristics of design. There is no perfect
solution. Our goal as programmers should be to develop the
ability to make informed decisions in these situations,
taking into account the context in which we are working.
Patterns document design solutions and so must be used with
care. One of the thing I love about the pattern form is
that it encourages the writer to make as explicit as
possible the context in which the solution applies and the
forces that make its use more or less applicable. This
helps the reader to face the possible trade-offs with his
or her eyes wide open.
So, one minor improvement @avdi might make in this chapter
is to elaborate on the reason underlying the assertion that
we can't eliminate this particular if check.
Otherwise, students of OOP are likely to ask the same
question my student asked.
Of course, the answer may be obvious to Ruby web developers.
In the end, working with patterns is like all other design:
the more experience we have, the better.
This is a relatively minor issue, though. From what I've
seen, "Confident Ruby" will be a valuable addition to most
Ruby programmers' bookshelves.
-----