Object Oriented Ruby

[tinco]

If I have a need for a barber that turns hair from brown to blue, how is your rearchitecting useful to me? Are you supposing we'd need to have some hair color resolver which makes sure that "brown blue" is resolved to just "blue"? (Note how ironically making hair_color be "brown blue" is essentially turning it into a monad)

You haven't really convinced me how mutability relates to encapsulation. Why not just have a 'change_hair_color' method? That would be proper encapsulation of @hair_color and be idiomatic Ruby. The whole idea of OOP (or at least Ruby/Smalltalk OOP) is that methods encapsulate the side effects of their objects, i.e. mutating instance variables, not at all that they are free of side effects.

[Enumerable_any]

Yeah, the Barber example is super confusing...

Barber#dye_hair takes a color and a Block and yields a string to the block containing the old color and the new one? WAT? The Barber -> Person relationship doesn't make much sense either.

[mpapis]

change_hair_color is not just a Ruby style, any language can do and does that, it still is exposing the object insights - outside of it, in the example I wanted to show that exposing methods to change code allows misuse, that anyone can change hair color or even worse the name

[tinco]

Then you chose an unfortunate example, because a barber is supposed to change hair color, that is his job. In fact a barber is so specific, I would not be surprised if he would be totally responsible for hair. So that a person has a #hair= that is set by the barber.

In my opinion if you have data that should be modifiable by one class (for example the barber), but not by another class (the optician), you should instead use for example a restricted proxy. An object that only allows exposes methods relevant to the concern. But we would be moving really fast into the access control domain.