Question

(Using Python 3.2, though I doubt it matters.)

I have class Data, class Rules, and class Result. I use lowercase to denote an instance of the class.

A rules object contains rules that, if applied to a data object, can create a result object.

I’m deciding where to put the (rather complicated and evolving) code that actually applies the rules to the data. I can see two choices:

1. Put that code inside a class Result method, say parse_rules. Result constructor would take as an argument a rules object, and pass it onto self.parse_rules.

2. Put that code inside a new class ResultFactory. ResultFactory would be a singleton class, which has a method, say build_result, which takes rules as an argument and returns a newly built result object.

What are the pros and cons of the two approaches?

Answer 1

The GRASP design principles provide guidelines for assigning responsibility to classes and objects in object-oriented design. For example, the Creator pattern suggests: In general, a class B should be responsible for creating instances of class A if one, or preferably more, of the following apply:

• Instances of B contains or compositely aggregates instances of A
• Instances of B record instances of A
• Instances of B closely use instances of A
• Instances of B have the initializing information for instances of A and pass it on creation.

In your example, you have complicated and evolving code for applying rules to data. That suggests the use of the Factory Pattern.

Putting the code in Results is contraindicated because 1) results don’t create results, and 2) results aren’t the information expert (i.e. they don’t have most of the knowledge that is needed).

In short, the ResultFactory seems like a reasonable place to concentrate the knowledge of how to apply rules to data to generate results. If you were to try to push all of this logic into class constructors for either Results or Rules, it would lead to tight coupling and loss of cohesion.