CODEWITHSUNDEEP
ruby-on-railsruby-on-rails-3
Spyros
Spyros

Reputation: 48706

Rails Polymorphic Association With Different Behavior

i want to create a polymorphic Queue association. I have two different queues in mind, one is about creating buildings, one is about creating units.

Though the queue has many same properties, like adding or removing items, there are some differences as well.

For instance, a building has a level, while a unit does not. The QueuedItem polymorphic class normally has some methods, like the remove one. However, a remove method is different, depending on whether the item is a building or a unit and needs different handling.

Moreover, the level column is totally insignificant to an army queued item.

So, my question is, based on those needs, what is the best way to design that ? Should i just go ahead with 3 models like (a queued item always belongs to a city):

Building
Unit
QueuedItem -> queued_id, queued_type, city_id

Or i would need to add more intermediate models ? What do you think ?

Upvotes: 0

Views: 131

Answers (2)

Bira
Bira

Reputation: 373

From your description, it appears you actually need classes for the queues themselves, not just for the queued items. So queue-related methods and operations go in the queue class, and stuff that's related only to buildings or units goes into those classes.

A Queue class would only include methods for adding, removing, and maybe reordering its elements, all of which are unlikely to require different implementations for different types of object. It's better that these methods have no side effects other than adding or removing from the queue - if you need something else to happen after an object is removed, for example, this can be done by the caller of Queue#remove. If do you need the queues themselves to behave differently depending on whether they contain buildings or units, then you'd need a BuildingQueue and a UnitQueue, both of which could inherit their common methods from a basic Queue class, or an included Queue module.

Other stuff specific to buildings and units (such as whether they have a level, or what their specific stats are) would go inside the Building and Unit classes proper. They don't need to know anything about how a queue behaves.

Upvotes: 1

zsquare
zsquare

Reputation: 10146

You could create a module with the logic for adding/removing from the queue and include it in both the classes. If you plan to use it in a lot of classes, you could also move it to a plugin, and add the helpers to the models which are to be implemented as queues.

Upvotes: 0

Related Questions