Hacker News new | ask | show | jobs
by nlawalker 3737 days ago
Can you expand on this? I'm not sure I follow, but maybe there's something particular to C++ here that I don't get as I'm not well-versed in it.

>> The issue with m->set_volume(.08) is it becomes difficult to tell what happens inside set_volume()

Isn't that the point? That you shouldn't have to care what happens inside set_volume? If mixer was designed and implemented well, then set_volume (along with the rest of its interface methods) should consistently and correctly handle its internal state.
1 comments
hintingonwhoiam 3737 days ago
Whether you are dealing with OOP, functional, or some other pattern it is always the point to create abstractions which you and others can forget about how they work.

Thus m->set_volume(.08) and set_volume(m, .08) should not require you to understand what happens internally as the user of either.

More generally in programming that is the point.

My only point is that of scope and essentially search space -- set_volume(m, .08) can only access the public interface of "m". While, m->set_volume(.08) could do almost anything to m. In a perfect world, with perfect programmers thinking the same way about what "set_volume" means or should do the separation of state and action would be less valuable.

This not to say OOP is > Functional or vice-versa. I think there is a place for both but that is a MUCH larger and more nuanced conversation :)

link