3

I have a signal processing pathway made of many classes. Each processing class is a composition of smaller classes, each of which have their own parameters.

Until now, I have been lazy and stored all of the processing parameters in a separate parameter class. I made this a friend of all of the processing classes so they could just access its data members directly. However, this makes for very strong coupling between the individual blocks and the parameter class, making the design completely inflexible.

I am redesigning the code so that each small process owns it's own private data members that it needs in order to function to reduce the coupling. But now, if a new set of parameters are loaded, I need a complex method that sets all of the parameters (using accessor functions) in each of the separate processing blocks. The commands within this method would be strongly coupled to the process. How do I minimize this coupling?

learnvst
  • 15,455
  • 16
  • 74
  • 121

2 Answers2

2

I'd suggest something similar to Context Pattern. On construction of your processes, load them with the context object or objects (you can have variety of contexts for various processes). Then let each process to request and retrieve necessary parameters from given context object. This way, you move the responsibility of setting process parameters entirely to those processes. In other words, process knows what parameters it needs, so process can request them from given context object and set its privately stored members directly.

Note, there are various flavours of Context Pattern, generally it's fairly flexible concept.

mloskot
  • 37,086
  • 11
  • 109
  • 136
  • This sounds great. Say that the values in the context object were to change after the processes were constructed. How could I allow the individual processes update themselves according to the new values? – learnvst May 01 '12 at 15:44
  • Here is what I have so far FYI: http://stackoverflow.com/questions/10401321/does-this-implementation-of-the-context-pattern-look-ok – learnvst May 01 '12 at 17:05
  • 1
    @learnvst You could make the processes subscribe (monitor) to context (publisher), so they are notified by the context automatically, in case of any change in the context. See http://en.wikipedia.org/wiki/Observer_pattern You could decouple publisher/subscriber responsibilities from the context itself, but it may be trickier. – mloskot May 01 '12 at 17:40
  • 1
    Thanks, that's really useful and backs up someone else's suggestion on the question linked above your comment. Thanks again – learnvst May 01 '12 at 17:45
1

You could develop either a generic context (with key/values in a map) or specific contexts that inherit from a SpecificContextBase, which would have parameters common to all processes.

The PROs of the GenericContext is that you dont have to change it to add/remove parameters, but the CONs are the lookup costs for accessing each parameter.

The PROs of the SpecificContext is there are no lookup costs to access parameters, but the CONs are the modifications to add/remove params. At least with this option, you should only have to modify the concrete Context class specific to one process which should not affect anything else.

Brady
  • 10,207
  • 2
  • 20
  • 59