So I am new to design patterns and C++11, but I have been studying both quite a bit. I am working on developing a C++ application to process some data, and I was hoping that someone with more experience could tell me if I am on the right track.

So the application will take in a large 2-D array of data. Then there is some preprocessing before passing the data to an object that will process the data. Finally, the results of the processing have to be post-processed to set up different types of plots and summary info.

So in studying the design patterns I saw that using the Command pattern or Strategy pattern might be a good fit. But at the same time, seems like I should use the Composite as a way to tie together the preprocessing, processing, and post processing. But I was concerned that tying together 3 objects into a composite might make a very large object--meaning that I would violate separation of concerns type rules.

The reason I want to use a design pattern is because I want a flexible way to add new type of preprocessing, processings, and post-processing chains to the application. So if today I produce one set of charts from the analysis, tomorrow there might be a new chart that someone wants. So I would need a way to add new types of requests or processing chains, without going in and breaking existing objects--which defeats the purpose of OOP design.

Any design tips would be appreciated.

EDIT Note, this question is distinct from: Choosing the right Design Pattern

The reference questions is a general questions about software design approaches. The questions I pose asks for a specific design recommendation based upon a set of requirements.

  • 8
    You're looking for the "computer program" pattern. Write code to accomplish your goal and use design patterns to describe what you did, not the other way around. – Blrfl Apr 24 '17 at 3:56
  • 2
    Possible duplicate of Choosing the right Design Pattern – gnat Apr 24 '17 at 4:45
  • @Blrfl not sure what you mean. If I already knew what pattern to use, I would not be asking the question in the first place. If you look at the meta for software engineering, it suggests that design questions are within the scope of this site. meta.stackoverflow.com/questions/254570/… – krishnab Apr 24 '17 at 5:13
  • The point @Blrfl makes is ignore design patterns, for the moment. Write a program that does what you want. If you then find yourself needing to talk to another programmer about what it does, compare what you wrote with you design patterns book's examples, and label those parts as such. See also the top answer to the linked question – Caleth Apr 24 '17 at 8:48
  • 3
    The "Choosing the right Design Pattern" answers your question by telling you that you are asking the wrong question. You don't choose design patterns. You design, and then you discover that you have used a design pattern. Patterns are something that you discover in your design after you have designed it. – Jörg W Mittag Apr 24 '17 at 10:08

It sounds like a job for Chain-of-responsibility (https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern) pattern. It allows for loose coupling so you won't have to use composition.

  • Thanks for the help. I was not sure which path to follow. Now I can see why Chain of Responsibility is a good choice. – krishnab Apr 24 '17 at 5:39

I think what you are looking for is an appropriate software architecture rather than a design pattern.

In your case, I think it will be helpful to study dataflow architecture and employ it in your particular situation.

I see the following distinct types of components in your architecture.

  1. Data source
  2. Pre-processor
  3. Processor
  4. Post-processor
  5. Data sink

The simplest instantiation of the architecture will consist of:

Simple Dataflow Architecture

A slightly more complex instantiation of the architecture may consist of:

More Complex Dataflow Architecture

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.