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.