The Ruby Module Builder Pattern

Ruby

Chris Salzberg

#internationalization-i18n

The Ruby Module Builder Pattern

by Chris Salzberg

In the talk titled "The Ruby Module Builder Pattern," Chris Salzberg explores the intricacies of Ruby modules, particularly focusing on the concept of module builders. The presentation begins with an introduction to modules in general, defining them as self-contained components with well-defined interfaces. Chris draws parallels between Ruby modules and modular designs in architecture and technology to emphasize their properties, such as standardization and customization.

Key points discussed include:
- Understanding Modules: Modules are key components in Ruby for achieving modularity. They can be included in classes, used for namespacing, and provide callbacks for inheritance.
- Flexibility in Design: The limitations of traditional modules lead to the necessity for module builders that can pass configurations dynamically.
- Metaprogramming: Chris emphasizes the role of metaprogramming in configuring module functionality, although it can introduce complexity.
- Module Builder Concept: A pivotal aspect of the talk highlights module builders, which allow the definition of modules as subclasses where methods can be defined in an initializer, enhancing flexibility and clarity in code.
- Practical Example: Using the 'edible' module, Chris illustrates how traditional modules limit flexibility and how a more dynamic approach with a method called ‘define_adder’ can enhance this design.
- Anonymous Modules: The use of anonymous modules provides a way to keep functionality distinct while also managing method definitions clearly, promoting better organization.
- Real-World Applications: The concept of module builders is applied within the context of the Mobility gem, showing how translation strategies can be abstracted while allowing for diverse storage backends.

Chris concludes that the implementation of module builders leads to improved maintainability and clarity in Ruby projects. He encourages attendees to explore these design patterns for enhanced modular programming. The talk fosters engaging discussions on metaprogramming and its complications while celebrating modular design principles in Ruby.

00:00:00.060 The next speaker is Chris Salzberg, and the title is "The Ruby Module Builder Pattern."

00:00:13.490 Hi everybody, my name is Chris Salzberg. I’m going to talk about module builders. What are the odds that Matt, the creator of Ruby, gets to talk about modules right before mine? I'm pretty happy about that.

00:00:27.150 So I'm a writer, programmer, and translator.

00:00:32.160 I'm known as Shioyama, and I have this gem called Mobility.

00:00:39.239 I'm going to talk a bit about that. I work at a company called Get Chica, and we have a booth in the sponsor area, so come talk to us if you're interested; we're hiring and based in Tokyo.

00:00:51.050 Okay, first, what I'm going to do is give a bit of an introduction. This is kind of the blog post that was the starting point for this talk.

00:00:56.969 It's a blog post I wrote on my blog a few months ago about modules.

00:01:02.219 It contains some fairly heavy Ruby concepts, and while I didn’t intend it to be a long thing, it ended up being quite extensive.

00:01:08.340 The article was about stuff I was working on in this gem called Mobility. I took about a month to write it, and after posting, I expected the Ruby diehards to find it interesting.

00:01:18.750 Surprisingly, it got picked up on Hacker News and other places and ended up getting about 30,000 to 40,000 views.

00:01:24.630 This surprised me because the content was relatively heavy.

00:01:31.619 Seeing this interest made me think it might be a good idea to take the topic further, so I proposed a talk at RubyKaigi.

00:01:37.710 Today, I'm going to take a little bit of a risk here. Instead of jumping straight into the blog post, which is heavy Ruby content, I'm going to take a few steps back and think about modules more generally.

00:01:44.430 I think it’s a good approach because Matt has set the stage with his whole talk about modules.

00:01:49.439 I want to consider modules outside of programming and apart from Ruby, and then see how much Ruby modules align with that idea.

00:01:56.189 So here's the idea of a module: programmers often have warm and fuzzy feelings about modules. Does anybody hate modules? Nobody hates modules.

00:02:03.570 But what the heck is a module anyway? Here’s one definition I found from Wiktionary: a module is a self-contained component of a system, often interchangeable, which has a well-defined interface to the other components.

00:02:10.259 This is a good definition because two key elements stand out: the self-contained part and the well-defined interface part. These will be important.

00:02:15.570 If we think about what an image of a module looks like, I did a lot of Google image searching before this talk.

00:02:22.380 To me, this image conveyed the feeling of a module. It has an interface with several connection points, indicating that it connects to other modular things. It is also self-contained.

00:02:29.280 This is actually a Russian space module. I know very little about space science.

00:02:34.740 In practice, we have lots of modules that connect together.

00:02:41.070 For example, my dad, an architecture professor, visited this interesting building in Tokyo called Naka Gin Tower.

00:02:47.370 It was built in the '70s and is very modular, allowing elements to be taken out and replaced.

00:02:52.950 Each unit inside the tower is self-contained and connected via a simple interface, which is just four screws. It's a bit scary but also fascinating.

00:03:06.480 Now, looking at another example, this motherboard for a Sony Playstation demonstrates modular design.

00:03:12.270 Here you have many different types of modules, each with its own interfaces, all self-contained. If they weren't self-contained, you wouldn't be able to get a game console out of this.

00:03:17.459 The idea of modular design aims to combine the advantages of standardization—which allows for cheap mass production—and customization, which can be costly.

00:03:23.880 Modular design is about encoding standardizable elements for mass production while allowing for some customization.

00:03:29.220 So, what elements contribute to modular design? First, you need an abstraction. This could be a living unit, a memory cell on a motherboard, or any common pattern.

00:03:34.980 Next, you define a well-defined interface. It's crucial to encapsulate the module and wrap it up behind this interface.

00:03:41.070 This is important because if you want to use a module in various contexts, you will face potential collisions with other things.

00:03:48.870 The broader you want your abstraction to be, the more different contexts you want to use your module in, necessitating a broader abstraction.

00:03:54.780 However, this requires your specification to be very expressive, capable of handling many types of interfaces.

00:04:02.010 You will also need tighter encapsulation because you will be using this module in many different places, and you won't know what kind of collisions may arise.

00:04:08.310 Now, that concludes my non-Ruby preamble, and I'll transition into Ruby. Matz already talked about many of these points.

00:04:14.100 In terms of modularity in Ruby, it’s viewed in many ways, but the first thing that comes to mind is the keyword 'module'.

00:04:20.670 Modules allow for modularity through inclusion. I listed here a collection of methods and constants.

00:04:26.760 As Matz pointed out, you can also use modules for namespacing, offering another dimension of functionality.

00:04:33.090 Modules also provide a callback method, specifically the included callback method.

00:04:39.120 Next, there's modularity through inheritance. We don't often think of this as modularity, but it is, as we reuse functionality.

00:04:44.130 You can subclass and share methods and constants. Again, there's a callback method for inherited modules.

00:04:49.950 In another sense, gems are also modules. You can try installing a gem called 'Dedica' if you have a console open.

00:04:55.920 It's a text adventure we created, and again, gems are modules—they're self-contained, with classes, modules, objects, and interfaces to their dependencies.

00:05:01.290 The key point here is that these gems are as flexible as their components allow.

00:05:07.470 For me, the starting point when thinking about modules was this gem, Mobility, I’m working on.

00:05:12.720 I won't dive into the details of the gem now, as it diverges from the topic.

00:05:18.300 The gem stores translations in a database, and abstraction is critical.

00:05:23.490 Many translation gems exist, each storing translations in a different way, such as in a JSON column or in another table.

00:05:29.190 Mobility abstracts all these storage strategies under one concept: backends.

00:05:36.570 Basically, it combines the functionality of five or ten other gems into one gem.

00:05:43.050 To achieve this, it abstracts these storage strategies into backend modules.

00:05:48.270 The gem then supports various plugins, many of which are built on this module builder concept that I’m going to discuss.

00:05:55.440 This was my motivation for exploring module builders.

00:06:02.010 There are wonderful aspects to Ruby modules, and I’m not going to criticize them.

00:06:08.310 But, they serve a basic purpose: I have my method, ‘foo’, and I include the module.

00:06:14.100 I can override it and perform method composition. That's acceptable.

00:06:20.670 However, are modules flexible? Let’s consider some pseudocode.

00:06:27.480 What if I want to use a module in a different context, passing some configuration into it so that it behaves differently?

00:06:35.550 If you attempt the given pseudocode, you’ll encounter errors, rendering this approach ineffective.

00:06:41.760 So the question arises, are modules encapsulated?

00:06:47.730 If a module defines a private method, and you include this module in a class, the private method should not be accessible.

00:06:54.490 However, that’s not how it works. If you include my module that defined ‘bar’, it overrides the original method.

00:06:59.390 What’s interesting here is that modules can create a sort of multiple inheritance situation.

00:07:04.100 Depending on how you use modules, if you're not careful, you can inherit many private methods—leading to a confusing mess.

00:07:11.430 So how do we address this issue? By harnessing the power of metaprogramming.

00:07:17.280 I love metaprogramming, and don't get me wrong—I’m not trashing it.

00:07:23.360 However, I’d challenge you to read and understand the code that represents metaprogramming—it can get convoluted.

00:07:30.500 In broad terms, metaprogramming often seeks to configure something in a module.

00:07:36.820 A lot of this stems from using a class and shoving the configuration elsewhere.

00:07:44.430 This approach piqued my curiosity, and as I dug into it, I concluded there has to be a better way.

00:07:50.500 Now I'll jump into the specific topic of my blog post about building with modules.

00:07:57.720 First, let's look at a small module called 'edible'. This module allows you to add coordinates.

00:08:04.050 It has a ‘plus’ method that takes a point object and creates a new instance with added coordinates.

00:08:10.370 I have a class called 'Point', which is a struct with X and Y coordinates. I include the module in my class.

00:08:16.060 When I perform the addition, I get the right coordinates, and it works.

00:08:21.680 Now, the issue is that including the 'edible' module requires accessors for X and Y, which limits the module's flexibility.

00:08:30.550 This limitation demonstrates the need for an expressive specification to support method composition.

00:08:37.460 The goal is to abstract a module so it can define addition based on any set of accessors, allowing for greater flexibility.

00:08:44.150 We can approach this with a concept called bootstrap methods. Let’s explore that.

00:08:50.360 We’ll define a method called 'define_adder', which accepts accessors and sets them up for any number of attributes.

00:08:56.970 The main point here is that we're now generalizing our method for multiple coordinate pairs.

00:09:05.670 Next, we can try creating a new class called 'LineItem', which has two accessors: 'amount' and 'tax'. This is different from our original 'Point' class.

00:09:14.090 If we include the previous version of the 'edible' module, it won’t work because it depends on 'x' and 'y'.

00:09:20.240 To overcome this limitation, we can extend 'define_adder' instead of including it.

00:09:27.920 By extending it, we can create configurable adders for the new class structure.

00:09:35.460 Now, when we call 'define_adder' with 'amount' and 'tax', we can see the expected flexibility in functionality.

00:09:42.320 We can add items and the math works as intended.

00:09:50.970 But how do we handle composition? If we redefine the method ‘plus’ with logging, we run into a problem.

00:09:57.680 The issue is that redefining it causes the new definition to clobber the old one, leading to inconsistencies.

00:10:06.040 In a class, methods don’t coexist: only one can exist per name—hence, redefining it leads to errors.

00:10:14.920 To resolve this, we'll need to redefine our methods on a module that’s included in the extending class.

00:10:20.890 Now, what we’ll do is create an anonymous module and define our 'plus' method there.

00:10:27.460 The beauty of this approach is that we can define methods inside the module while keeping them distinct.

00:10:34.990 Now, when you call the original 'plus' method from the class, it references the method in the ancestor module.

00:10:42.450 The assignment of methods is done in a way that respects previous definitions, avoiding errors.

00:10:49.590 Using anonymous modules enhances readability, and this method is frequently employed in Ruby frameworks like Rails.

00:10:58.550 This technique is visible in ActiveModel's attribute methods, which also employ anonymous modules.

00:11:05.150 When you create an anonymous module, include it, and define methods, the clarity becomes manifest.

00:11:13.170 Recapping, we explored three types of 'plus' methods: one with fixed accessors, one using a definer, and finally, using an anonymous module.

00:11:20.310 These examples illustrate the flexibility and expressiveness of the Builder pattern in Ruby modules.

00:11:28.340 In my blog post, I provide further details, but I won't dive into them here to keep the focus.

00:11:36.780 I looked at the example of attribute methods from Rails to show how they extend functionality through modules.

00:11:44.810 For instance, the module being extended defines methods via a bootstrap method, which adds to the system's modularity.

00:11:52.420 My concern is that this modular approach can lead to scattering of functionality across multiple locations.

00:12:00.970 The class has state, the module extends it, and this division raises a question about coherence.

00:12:06.290 I don't perceive this as truly modular since it can become difficult to track methods across differing blocks.

00:12:12.130 Now, let’s transition to talking about the module builder.

00:12:20.450 This diagram from a book on metaprogramming in Ruby outlines Ruby's core object model.

00:12:29.090 Here we see different objects, classes, and their subclass relationships.

00:12:35.970 An interesting observation I made while preparing my talk was how the relationships are depicted.

00:12:41.470 This diagram misses an important arrow, highlighting how modules relate to classes within Ruby.

00:12:47.690 Here’s the kicker: a capital 'M' module is a class itself.

00:12:57.950 While a small 'm' module can’t do everything a class can do, capital 'M' module certainly can.

00:13:04.900 Capital 'M' modules can have subclasses, which in turn can define their methods.

00:13:11.490 Inside a method of a subclass, I'm able to define that module's methods.

00:13:17.580 This might look strange but it’s essentially just combining familiar concepts in a new way.

00:13:24.390 This concept is what I term the 'module builder.'

00:13:29.920 I believe module builders offer significant advantages, as they encapsulate configurations into a cohesive unit.

00:13:35.390 This entails an initializer that allows you to configure the module.

00:13:42.660 In the initializer, you can define methods as necessary.

00:13:49.720 To substantiate this, consider the example from earlier, defining a plus method in the module.

00:13:56.780 This is a clean, concise way to define functionality without cumbersome modifications.

00:14:03.450 You can maintain organized and expressive code while including instances into classes clearly.

00:14:09.590 This emphasis on encapsulation leads to an intuitive understanding of your codebase.

00:14:17.100 Ultimately, using module builders enhances flexibility and ease of use.

00:14:23.730 Now, there are numerous ways to implement this design pattern throughout your Ruby projects.

00:14:29.390 For example, I recently discovered a gem called Alchemist.

00:14:36.360 The author cleverly utilized a module builder to structure their code, making it more maintainable.

00:14:43.520 With a clear initializer setup, the entire architecture became streamlined and readable.

00:14:52.030 Additionally, another gem, dry-equalizer, adopts similar principles for comparative analysis.

00:14:59.470 It showcases how useful module builders can provide succinct implementations without excessive boilerplate.

00:15:06.530 In conclusion, Mobility is a perfect context for implementing module builders.

00:15:13.620 It allows building backend strategies to store translations efficiently while maintaining modular and flexible configurations.

00:15:20.360 To facilitate those, I create module builders that customize module loading and execution on demand.

00:15:27.030 What surprised me most after posting the blog post is the reception toward the terminology 'module builder'.

00:15:34.140 I expected criticism, but instead, I found people more concerned with metaprogramming.

00:15:40.540 To me, metaprogramming represents one of Ruby's strongest features.

00:15:48.410 At its core, module builders are a simple twist on metaprogramming—it's just a subclass that’s configurable.

00:15:54.600 This design is straightforward, and I believe you can harness it in numerous ways.

00:16:01.840 So, I encourage you to explore the module builders concept, as it can be applied effectively across your Ruby projects. Thank you!

00:16:15.630 Sure, it's kind of specific, but in your examples of module builder, you were often including the module and then calling new on it, passing some parameters.

00:16:22.300 In your example with Mobility, you have this 'translates' keyword. I'm just wondering why there's this distinction.

00:16:33.860 Actually, it's mostly that Ruby developers find it confusing to include something that's an instance.

00:16:39.590 There's no technical reason; it's purely a syntax or human intuition issue.

00:16:46.190 The dry equalizer gem uses a different approach by defining 'equalizer' on the module directly.

00:16:50.780 The rationale is that people find this intuitive, even if there's no significant technical advantage to derive.

00:16:58.090 So, it’s purely a syntax issue.

00:17:04.930 Do we have any further questions? We have about five minutes left.

00:17:16.840 I understand you have a well-thought-out article detailing these concepts.

00:17:23.570 I'd be keen for you to translate this article into Japanese—it's a small request.

00:17:31.540 Thank you very much!

00:17:38.680 Would you like to have a few last remarks?

00:17:43.590 As a quick note, configuring modules can enhance capabilities significantly.