ok … once again a co-worker and I are having some disagreements on
some setup issues …
scenario:
- using TCPDF (derivative of FPDF)
- inheriting TCPDF to create our own class to do some basic stuff we
need.
- going to further inherit our own class to create further specific
functionality (ie: Report, Invoice, etc.) these will take care of
things like specialty header/footer, layout, etc.
Best layout for this??
Currently TCPDF is in vendor/plugins as it should be, but our
specialty stuff remains a mystery. In ‘lib’ since it can be a library,
or in app/models since it is technically a class … however, that’s
usually better for database models (ie: tables) … I’ve seen some
apps (ie: redMine) create it as a module in app/helper … or should
it all remain in lib?
Your thoughts?
You might want to review your Patterns book, but you can sometimes avoid
inheritance by using the strategy pattern.
For example. Employee is a class. Hourly employee is a subclass of
Employee and Salaried Employee is a subclass of Employee. If you want
to make an Hourly Employee into a Salaried Employee you have to use some
trickery but the net result is you destroy one object and create
another. You could also have an Employee class and a Payment Strategy
class which has two concrete subclasses Hourly Payment and Salaried
Payment. Now you can just affiliate an Employee with the appropriate
payment strategy.
You could also create modules and use a kind of multiple inheritance.
Invoice inherits from Report, which includes the following modules:
Invoice Header, Invoice Body, Invoice Footer and PDF Renderer. So, in
your Invoice, you just call build_header; build_body; build_footer;
render.
You could subclass Report as Invoice, which will implement its own
build_header, build_footer, build_body methods and then use the
renderrer (PDF, HTML, etc.) as a strategy…
The point is there is no one way to do it, but inheritance isn’t the
only want to approach your problem. Although, depending on your design,
it may be a very valid way to address your issues.