Day 10 – Program organization, Part 2 of 3.
As an experienced information architect, I’m familiar with the challenges of declaring an organizational structure. Whether its for books, furniture, clothing, or software, every structure has it’s biases – somethings are easier, others more difficult. With this in mind, the goal is always to net a more sustainable, maintainable, self-evident state.
Ruby’s include (for modules) and require (for files) commands make organizing code into separate files for easier maintenance possible. The question is how.
Jen once quipped about working in retail, “I can’t sell it, if I can’t see it.”
The same is true in programming, Slagell reminds us, “…for Ruby to include a module, it has to be able to see that module.”
Therefore, the chunk of code to be included should either be in the same file as the include command or the appropriate file should be required. Otherwise, mixing metaphors, the product isn’t really on the floor.
In today’s exercises, Slagell asks us to think about how to organize a program that shuffles a deck of cards.
Here are my initial thoughts:
- Both “deck” and “hand” are collections of “cards”, differing by the specific number of “cards” contained. Therefore, “deck” and “hand” should be subclasses of a larger “collection” class.
- It maybe desirable to reorder both the “deck” and a “hand”. So, the action of “shuffle” should be applied at the “collection” level.
- “Card” should be it’s own class with “suit” and “rank” properties.
This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.