Homepage

Basic Ruby on Rails Design Patterns

Patterns make life easier. This applies also or, we can say, especially to the world of web and software development. In Ruby, design patterns are ultra-efficient in terms of keeping the code and model lightweight, slim and repetitions-free. Here’s how to use two main patterns: service and decorator.

Not only as programmers, but in day-to-day life, we encounter some problems. Every person has similar difficulties, and our society has found universal ways, patterns, to solve that problems. As programmers we also have problems, which can be solved by patterns. Our beloved Wikipedia says:

Software design pattern a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

Wikipedia

Software design pattern definition

And I must say I love that definition. There is nothing more to explain.

I’ve chosen two design patterns I found the most common in Rails world - service and decorator. Main reason why they are so common is that they help keep models slim and DRY through moving great part of logic into other parts of application. And of course slim models are good models, so better learn those two design patterns!

Service

Service is by far my most used design pattern in Rails applications. The idea of this design pattern is very easy - if certain part of business logic doesn't really fit into model or controller, it may be good idea to put it into service. You can then use your service in multiple places, like models, controllers, jobs etc, keeping you application clean and DRY.

Default Rails app structure doesn't have folder where we can put our services. So we have to make one! Create services folder inside your app directory.

tsx

Now, when we have a place to store our servies, let's define base service, so that we are sure every service uses the same interface to communicate with the rest of the application.

tsx

That's it! Only one method, nothing more. Now, let's jump to the actual service.

tsx

Methods initialize and call are a must-have. If call method would be too long or complicated, it's best to create additional methods in private section. That's because only call method should be available outside of the service.

Decorator

In OOP, decorator gives us ability to extend particular object's behavior by equipping it with some additional methods. In Rails ecosystem I've usually seen this design pattern being used with draper gem.

Draper is useful when we have methods in models, which are used only in views. Using decorator design pattern means putting in them every bit of logic which is used only in views. So, if in User model we have method full_name, e.g.

tsx

We should move it into UserDecorator.

tsx

Great thing is that not every user object in views will have that method, we have to decorate that object before sending it to the view, simply using user.decorate. So in controller we have to use:

tsx

And then, we can use this code in our views:

tsx

That’s all?

Of course not, you silly! The world of design patterns is a lot lot bigger than that. Not every of them would be applicable in RoR application, though. Or that particular problem you have. But still, it's very good to know some design patterns, even their main ideas. Because maybe one day, you'll have some problem and it can be solved with design pattern you know or at least heard of. Or maybe you will develop your own design pattern, that will be described in books? ;)

Let’s Create a Great Website Together

We'll shape your web platform the way you win it!

More posts in this category