OmbuLabs Blog

In my previous post, I mentioned how I was having issues with populating my random maze. The main problem is that there isn’t a clear way to programmatically add random rooms and paths between those rooms. I ended up with a method way more complex than I wanted and that only did the most basic thing, which was to add random types of rooms and just connect them randomly as well, but without verifying any form of room placement, for example.

This is a clear sign that we need another layer of abstraction. We need something that can hold our maze data and to take care of placing the rooms and connecting them according to the rules we establish. After some research, I think I found the right alternative: the Graph.

So, our little exercise in design patterns is getting quite messy. Which is ironic, considering it’s an exercise in design patterns.

The reason is that I’m mostly trying to be very focused on the Design Patterns book and just fleshing out the example implementations they provide.

Therefore, in order to organize things, I believe this is the right time to add unit tests. As a plus, I also get to test my little gem in an automated fashion.

Here I’ll only go through the RandomMazeBuilder class since it would be quite lengthy to go through every single file. To see all the other specs, just checkout the repo.

In the last part of this series, we left our little maze game gem generating random mazes that had random kinds of rooms using the abstract factory pattern.

While that was good enough, in the case of the our maze game, it turns out mazes can be pretty complex objects, being a collection of rooms, doors and walls of many types. And even though I didn’t add too much variety of these components, things could get pretty convoluted.

It turns out there’s a pattern just for these cases: the Builder Pattern.

In my last article I introduced this series and here’s the first pattern: the Abstract Factory

It’s been a few months now that we’ve been toying with Elixir here at OmbuLabs. Particularly with Phoenix. However, I like to toy a bit with the language without the added complexity of a framework on it, in order to better understand it, how it works and how things are done.

It took me a while, but as I read through “Programming Phoenix”, I had the idea to implement a “simple” calculator program in Elixir. The reasons were quite simple:

• I wanted to better grasp unit testing with ExUnit, and a calculator has very clear specifications, making it the ideal candidate.
• I also wanted to put a little twist to things and while math has very clear specs, it can have some very complex operations, so I decided to make my calculator do derivations.

For those of you that aren’t versed in calculus, don’t worry, I’ll give just what you need to know in order to understand what I’m doing, but trust me, you won’t need to really understand calculus to understand the code.

The title says it all, but how does one actually implement object oriented design patterns in Ruby? If you’re like me and always struggled with putting what you read about programming into an actual implementation and the examples in the book or around the internet weren’t enough to quell your doubts, read on.