OO vs pure functional design

I am having a little confusion as to how we can have both OO and pure functional design. In the section Writing Good Code-Method Decomposition there are a few paragraphs saying this:

A good general goal is that your methods should be like a mathematical function: it should take something in and return something. It should not rely on anything besides what is explicitly passed in, and it should not have side-effects; it should communicate its result through the return value.

Some languages are stricter than Ruby: they don’t allow you to use any data except what is passed in as an argument, and they don’t let you change any outside (“global”) variables variables, or communicate outside except through the return value. Ruby is more flexible, but the majority of methods should be written in this style.

Simply put: the only way in should be the arguments, the only way out should be the return value.

Now I completely agree with this, I think code that is pure and has no side effects is pretty much easier to understand and reuse 100% of the time, but then just a few sections later (in refactoring) we are talking about OO design with examples like:


In bicycle.rotate_tires you are mutating the bicycle object instead of saying:

bicycle = rotate_tires(bicycle)

which has no mutations

or probably better:

bicycle.tires = rotate_tires(bicycle.tires)

I know exactly how the bicycle.rotate_tires example works. We know it is mutating the state of bicycle since it is being called under the bicycle object. Maybe some people would be unhappy that one might use the second version, but just like the paragraphs above say, the take something in and return something approach to programming generally results in shorter and easier to understand code.

Here is a reading about that if anyone wants to better understand what I am saying:

1 Like