I have PDF generation feature in my app. I am using iTextPDF for generating reports, so it works well. The problem is not exactly in pdf generation but in approach. Currently PDF generation code looks horrible, hard-coded and not flexible, so there is a lot of duplication and everything is highly coupled.
Are there any best or common practices for such a task? Maybe some architectural approach or pattern?
I would be very grateful for any advice and code example that was proven as reliable and flexible.
Best Answer
As long as you want only a PDF version of your report, it's enough to simply apply good factoring practices. Write utility functions, extract common code into subroutines, choose good method names, and after a while you'll have a pretty decent maintainable report generator.
However, the second it looks as if you'll have to support any other output format than PDF for the same report (e.g. text, HTML email, whatever), immediately refactor your code into a generator (decides what information to print and in what order) and a renderer (knows how to produce bold, centered, or double-spaced output).
Then, whenever the report content changes, you only have to update the generator, and whenever the style requirements change, you only have to update a small part of your renderers. And when yet another output format is required, you only have to add another renderer subclass rather then walk through your entire codebase yet again.