1

At the end of a flow of operations, there is a printing module that gathers data from the various sources involved (Customer, Order Header, Order Content, User, Payment, ...) to build a summary receipt or report printout. What should be the appropriate pattern in order to pass data to this module ?

In the existing code, data are passed such as :

Print print = new Print();

// then a very long list of info
print.PaymentInfo1 = ...;
print.PaymentInfo2 = ...;
print.CustomerInfo1 = ...;
...

// Then I print
print.PrintReceipt();

The idea is to gather the various object in one entity. I have seen the Composite Pattern, the Facade and the Module Pattern. What pattern is the best adapted ?

I was thinking instead about something like :

Print print = new Print();

// then only the sources involved
print.AddPayment(currPayment);
print.AddCustomer(currCustomer);
...

// Then I print
print.PrintReceipt();
Yahia
  • 805
  • 7
  • 25
  • Post some more code. At the moment it's hard to understand what you're trying to do. – Sriram Sakthivel Sep 18 '15 at 09:56
  • Who decides how something is printed (i.e. how a payment looks like etc.)? Is it the printer or the payment? The visitor pattern might decouple this dependency. For storing the data, I don't see what's wrong with storing the entities in a single (sorted) collection (or maybe per-type collections). – Nico Schertler Sep 18 '15 at 10:21
  • The printer class manages the layout of the printout by taking a piece of info from eg payment, another piece from customer, etc. – Yahia Sep 18 '15 at 10:24
  • With the existing code, the issue is that the list of info is very long and impact the readability. Second issue is the printing class is used from another processes in the application for another type of receipts (different set of data) – Yahia Sep 18 '15 at 10:27
  • @NicoSchertler I don't see any hierarchies - Visitor is killing a mosquito with an atomic bomb. – Fuhrmanator Sep 18 '15 at 16:16
  • What is the problem you're having? Design patterns solve recurring problems. They're not tools you just apply arbitrarily. `Passing data to a module` is not a problem of any design pattern I know. Does your solution currently work? Are you having trouble maintaining the code when the requirements change? – Fuhrmanator Sep 18 '15 at 16:18
  • I'm voting to close this question because there is no specific problem here, only one about design. _["there is no actual problem to be solved"](http://stackoverflow.com/help/dont-ask)_ –  Sep 21 '15 at 23:27
  • I agree the question is not very precise. But the issue is real and I believe not rare. The real trouble is typically how to make sure all the critical info are filled before being passed to the Print class. Otherwise you start having nullreference exceptions. Should we pass the data granular ? The question becomes, I have class A, B, C whom some members of each are needed by the class Print. What is the most maintainable way to pass info to class Print ? – Yahia Sep 22 '15 at 07:59
  • @Sisyphus has [here](http://stackoverflow.com/questions/5334353/when-should-i-use-composite-design-pattern) a nice real world example of the composite pattern. Now I see this pattern does not apply to the question. – Yahia Sep 26 '15 at 21:49

0 Answers0