While the dataflow section hopefully convinced you that there are circumstances in which a dataflow approach is useful, please keep in mind that there are many circumstances in which this is not the case.

First, a dataflow approach really only makes sense when the underlying task is really about the flow of data through the components that process it. If you can't sketch a concise data flow diagram which truly represents the application, the dataflow approach might not be the best option. For example, if you are implementing a complicated algorithm which is really about the sequence of instructions that need to be executed on the data (rather than the data going through well-defined and self-contained processing components), you probably should't use the Signal Network library. If you are working on an audio or video processing application, maybe you should.

Second, using signals as the underlying data transport mechanism makes the Signal Network library inherently a run-time contraption. Every signal sent results in a function call, and if the processing components are so minute that the cost of the function calls overtakes the cost of the processing, using the Signal Network library will cause a significant performance hit.

To sum up, consider using the Signal Network library when: