oop

I’ve been promoting a functional approach in Ruby for a while now and even though it includes many different techniques and patterns, there’s this one idea, one fundamental idea that changes everything - immutability. But what does it even mean in Ruby? To freeze everything? That would be too slow, so no. Immutability-oriented design means that you avoid interfaces that can change your objects. Yes, there are plenty of methods in Ruby to mutate something, but when you are designing your object interfaces, you can design them in a way that your objects won’t change....

You think you’ve done everything with Ruby? How about subclassing Module? It’s an interesting technique that I’ve been experimenting with lately. One of the downsides of using modules in Ruby is that a module doesn’t have a state. When you mix it into another class you’re basically copying methods from one place to another. What if extending an object with new methods requires a state? Where would you put that state?...

A few weeks back we had a small drama about SRP. There were some smart comments, some stupid ones and a few funny jokes even, like that for example: https://twitter.com/porras/status/220456288017059840 If I remember correctly it all started with this post. I’ve seen criticism on twitter saying that the post shows shitty code, that it’s more complex than it should be, that User class is definitely the best place to put code that creates a user and so on....

This is a post from the Get Rid of That Code Smell series. Primitive Obsession is another popular code smell in Ruby land. It’s very easy, tempting and just feels convenient to use primitive objects to represent various concepts in our code. Here are some primitive classes in Ruby that we like to be obsessed about: Array Hash String Fixnum Float Whenever you use one of these classes in a context where they don’t actually fit being semantically incorrect, that’s when you introduce Primitive Obsession code smell....

This is a post from the Get Rid of That Code Smell series. Removing duplication from the code is a seemingly easy task. In many cases it is pretty straight-forward - you look at similar bits of code and you move them to a common method or class that is reusable in other places. Right? No, not really. It is true that code that looks similar might be an indicator that there’s a duplication but it’s not the definitive way of determining the smell....

This is a post from the Get Rid of That Code Smell series. If you are serious about Object Oriented Design and respecting Single Responsibility Principle then you definitely want to get rid of Control Couple code smells. In this post I will show you a simple example explaining how to identify and remove control coupling from your code. I like to think about that code smell also in the context of SRP because I like to apply it to every piece of my system - whether it’s a method, a class or a whole library....

In this post I will show you why using attribute accessors is a code smell in most of the cases. This is a very convenient feature of Ruby but you should only consider using it if you’re implementing a data-like objects which expose, well, data to other parts of your system. A good example is an Active Record object which exposes its attributes. Another good example could be an object which wraps a response from a remote API and through attribute readers gives you access to data returned in that response....