Down with Helpers!
Up with Decorators!

Why helpers are great but decorators are even nicer!


David Worth - dave@highgroove.com

Helpers are great

They move business logic out of and views into a testable unit:

What's wrong with helpers?

Flat namespaces lead to collisions:

What's wrong with helpers? (con't)

I had no idea what the load order for helpers was.

What is the Decorator Pattern? (con't)

From the Wiki:

In object-oriented programming, the decorator pattern is a design pattern that allows behaviour to be added to an existing object dynamically.

Pretty much.

What is the Decorator Pattern? (con't)

But it gets better:

The decorator pattern can be used to extend (decorate) the functionality of a certain object at run-time, independently of other instances of the same class, provided some groundwork is done at design time.

What is the Decorator Pattern? (con't)

Neat! But how?

This is achieved by designing a new decorator class that wraps the original class.

Think proxy classes!

What is the Decorator Pattern? (con't)

There is a wealth of OO literature on the subject...

Introducing Draper!

Draper adds namespaces to helpers!

How does it work?

Proxy objects of AREL proxy objects

It slices

Draper handles associations gracefully too

It slices

Draper handles associations gracefully too

It dices

Decorators are a great place to put output formatters for things like XML, JSON, CSV that may need custom formatting.

Putting these presentation concerns in your model should feel funny...

It dices

It dices

Note the alternative decoration syntax above.

(This idea blatantly lifted from the docs)

It even enforces interfaces

References

/