I have a Rails application (something like an online catalog) that needs
to
behave differently for different types of clients. For example, boat
dealers
and car dealers.
- When the application displays a list of cars, it needs to list car
attributes, like horsepower and gas milage.
- When the application displays a list of boats, in needs to list boat
attributes, like LWL and sail area.
I would normally use the Strategy design pattern to implement these
different types of behavior.
But with Rails, it seems much more natural to implement the different
views
of the data as partials, with the car-data view in one partial and the
boat-data view in another partial. The application can then include the
boat
partial for boat dealers, and the car partial for car dealers. The
application can be extended for other types of dealers simply by adding
a
new partial.
This solution separates out the stuff that changes (the view of the
data)
from the stuff that doesn’t (the stuff that creates the list of
inventory
‘items’), and keeps the car-view code separate from the boat-view code.
Furthermore, using a partial doesn’t seem hugely different from using a
Proc
object, which was the first Strategy solution I thought of.
In other words, using partials seems a more Rails way of implementing a
Strategy-like solution, at least when viewing data. However, it’s not
very
OO, and I feel guilty using this easy ‘cheat’.
Has anyone else run into this issue? Your thoughts much appreciated.
Brgds: John
On Feb 15, 10:25 pm, Identry [email protected] wrote:
This solution separates out the stuff that changes (the view of the data)
from the stuff that doesn’t (the stuff that creates the list of inventory
‘items’), and keeps the car-view code separate from the boat-view code.
Furthermore, using a partial doesn’t seem hugely different from using a Proc
object, which was the first Strategy solution I thought of.
In other words, using partials seems a more Rails way of implementing a
Strategy-like solution, at least when viewing data. However, it’s not very
OO, and I feel guilty using this easy ‘cheat’.
Why? Who are you cheating? Sounds like somewhere along the line you
absorbed some OO dogma. Most OO dogma is about going to extra trouble
today to save trouble tomorrow. Forget about it. Save tomorrow for
tomorrow, think about today instead. Just write the code in the
simplest possible way. If becomes awkward later, change it. Your
functional tests will validate the change.
Agreed!
I am assuming that somewhere along the line you have some way of
determining the dealer type (STI?). Why wouldn’t it be ‘OO’ to do
something like:
render :partial=>“show_#{dealer_type.underscore}”
Well the OO-Rails-Way to solve this is to have a model for Cars and
one for Boots. These Models would typically inherit from some vehicle-
class if u have common attributes and functions.
You can then display Boots and Cars in their Views and not in some
other View where they don’t belong. Just redirect to the appropriate
view for the your dealer
I don’t think there’s any confusion about the different models to use,
the question is the best wasy to “display Boats and Cars in their
Views…” Strategy Pattern answers that problem by giving a mechanism
to perform that view selection.
On Feb 16, 3:25 pm, “[email protected]”