0

I'm working on a task managing application which uses a ResourceManager to manage all the reservations of different Resources, each with their ResourceType. At the moment, there are 5 kinds of ResourceTypes and these will not change regularly, but it can occur.

My question is what would be the best way to approach the design for this in terms of OO design, GRASP principles and the overall maintainability of the code:

  • Option A: seperate classes Resource and ResourceType + ResourceManager class will keep a multimap of resources for each resource type

  • Option B: seperate class Resource + ResourceType class will contain a list of its corresponding Resources.

It seems to me that with option B, there'd be a higher cohesion concerning resources and their types, but I'm looking for certain (refactoring) scenarios in which one option will come out better than the other?

SND
  • 1,552
  • 2
  • 16
  • 29
  • Shouldn't the specific types inherit from an (abstract) parent Resource. You then don't need the ResourceType class and the ResourceManager has a map of all the Resources. – Erwin de Gier Mar 27 '15 at 12:47
  • The types are determined at runtime, so type is not a specific class, but rather just a name and some additional properties depending on what kind of type input is. A resource just has a specific resource type, but all resources have the same kinds of properties. – SND Mar 27 '15 at 13:09
  • From an OO point of view, I think the ResourceManager should not be aware of the different ResourceTypes, differences should be handled internally in the Resource class. That rules out option A. If you now have 5 fixed kinds of ResourceTypes, you can still make them into 5 subclasses that are instantiated at runtime depending on the input? – Erwin de Gier Mar 27 '15 at 13:17
  • ResourceTypes are not fixed, so using subclasses is no option. Also it should be efficient to get all Resources of a specific ResourceType, therefore there would either be a MultiMap in a ResourceManager OR a list in ResourceType. But no inheritance can be practically used afaik. – SND Mar 27 '15 at 13:25

1 Answers1

1

This would allow types to be represented as classes and added at runtime.enter image description here

You could also have a ResourceFactory which decides which resource to make at runtime. Then you could use the factory to get the resource object to pass to addResource().

The benefit of this design is ResourceManager is decoupled from the specific resource types it manages. To add a new resource type, just add a new class and update the factory class.

Chronos
  • 91
  • 1
  • 12