Enterprise Rails

Refactoring: Inheritance and Mixins

Since we know our website’s purpose is to sell movie tickets, it makes sense to add tables to hold sales data before we begin coding up the front-end. Figure 6-6 shows our first stab at adding tables to store orders and ticket purchases. The orders table holds each transaction, including the purchaser’s name, address, and credit card information. The purchased_tickets table is a line item table for each ticket purchased in the transaction. Rather than simply providing a column in the orders table to record the number of tickets purchased, we split up the tables, foreseeing the need to account for tickets at different prices, such as student or senior discounted tickets, matinees, and so on.

In adding these extra tables, we find a glaring violation of the Don’t Repeat Yourself (DRY) principle. The violation of DRY occurs in the repetition of address data between the theatres table and our new orders table. If we kept the schema as is, with the data duplicated, we would also end up duplicating a lot of other code, including validation code and display logic for addresses.

Figure 6-6. Theatre tickets data model with orders and purchased_tickets table, but with address schema repeated in two tables

Instead of duplicating this structure, we create a separate addresses table. If mimicking the previous examples, we would create address_id columns in the ...