# Module/Class Best Practices

**URL:** <https://www.ruby-forum.com/t/module-class-best-practices/129833>\
**Category:** Rails\
**Created:** [February 21, 2008, 11:37pm UTC](https://www.ruby-forum.com/t/module-class-best-practices/129833 "2008-02-21T23:37:34Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Brenton\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/f475e1/32.png) [@Brenton\_B](https://www.ruby-forum.com/u/Brenton_B)\
**Post date:** [February 21, 2008, 11:37pm UTC](https://www.ruby-forum.com/t/module-class-best-practices/129833/1 "2008-02-21T23:37:34Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Brenton\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/f475e1/32.png) [@Brenton\_B](https://www.ruby-forum.com/u/Brenton_B)\
**Post date:** [February 21, 2008, 11:54pm UTC](https://www.ruby-forum.com/t/module-class-best-practices/129833/2 "2008-02-21T23:54:02Z")

</div>

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.