Skip to content

Object Oriented Design Tips with Ruby – Part 1

In recent years the Object Orientation paradigm has been increasingly applied and spread within the software development community. Proof of this is that the vast majority of new languages ​​that have emerged in recent years follow this paradigm. Object-Oriented development has several advantages and aims to make development simpler, focused on greater abstraction and code reusability.

Among the several existing readings on the subject focusing on the Ruby language, which is the main language on our Stack here at Resultados Digitais, one of the ones I liked the most (and recommend) was the book POODR by author Sandi Metz, which includes in its content lots of techniques and tips on how to get better design and cleaner architecture in Ruby code.

In this sequence of posts, I selected some of the tips that most caught my attention and that, if applied, can bring benefits to the code developed on a daily basis.

Encapsulate instance variables

One of the first tips the book brings is about using instance variables in classes.

However, the code above can be improved by applying some simple object-oriented design tips, they are:

  • Work with behavior rather than direct use of instance variables.
  • It is important to use an accessor over the variable to avoid using its value directly.
  • If the variable is only used within the class and does not need to be exposed in the instance, it is possible to protect the attribute with the private visibility modifier.
  • Is the Person class’s age attribute only used within the adult method? to do a check, so there is no need for it to be exposed by a public accessor, so it was possible to use a private accessor.

Avoid using hidden structures

  • Another important tip is to avoid using hidden structures in the code, such as methods that use array positions in their implementation

Other tips to avoid using hidden structures are:

  • Whenever possible use Struct instead of working with a hidden structure or array position.
  • Avoid methods that rely on multiple hashs or arrays as these structures can change easily.
  • These implementations do not encapsulate behavior and expose themselves directly to code.
  • Avoid using structures like array[1] as it is not possible to know their actual behavior or what this position represents.
  • Avoid using numeric values ​​or regular expressions dropped by the code, preferably by assigning those values ​​to a variable and then making use of it.

Applying Single Liability Principle (SRP)

The Single Responsibility Principle and Responsibility Principle Single is the principle that holds that every class should have only one responsibility, ie to be responsible for performing only one function within the system. But this principle can and should also be applied to methods.

A class where all its methods comply with the SRP becomes more cohesive and brings design improvements to the class as a whole, as small methods focused on only one function facilitate reuse, in addition to being easily extracted to another class and reused in the application as a whole.

Final considerations

  • The starting point for good code architecture, organization, software that is easy to maintain and reuse is to try to make classes and methods always have only one responsibility.
  • Classes/methods that comply with SRP allow for non-consequential changes at different points, facilitate reuse, refactoring and reduce duplication
  • Avoid using comments as they are forgotten and are not updated as the code changes.
  • When a code has lots of comments, there’s a good chance that code has too many responsibilities assigned and that code should be separated into other methods or classes so that each has only one responsibility.

Are you applying the practices set out above in your codes? Do you have something to add?