Is there a recommended design pattern for communic

2019-07-19 01:26发布

问题:

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?

回答1:

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.



回答2:

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.