Hacker News Reader

Comment by wwalker3 | Hacker News Reader

The author's objection to data encapsulation seems to be that for an object X, the internal state produced by "X.a(); X.b();" may be different from that produced by "X.b(); X.a();".

But this behavior is exactly what makes an object. Programmatic objects are supposed to be analogous to real-world objects. If I shift my car into first gear, then turn the key to start the engine, I get very different results than if I do the reverse.

Even abstract mathematical objects like vectors and matrices work this way. If I rotate a 3D vector twice, the final direction it points depends on the order I do the rotations in.

View on HN

Your examples ignore the way that data encapsulation is used though. You can inspect the position of the gear lever in your car before deciding what to do next. A vector rotation relies on no external state whatsoever.

A better example would be if you had a counter hidden somewhere out of sight which counted the number of times you turned the key in your car, and introduced different behaviours for key-turning based upon that value.

Ok, so you've proven that an OO design can be badly thought out, which is also true of every other programming style.

> A better example would be if you had a counter hidden somewhere out of sight which counted the number of times you turned the key in your car, and introduced different behaviours for key-turning based upon that value.

Interestingly enough, every car does have something like that. (Think gas, maintenance, and repair.)

The real world does have mutable state.

Your "better" example is almost exactly true of my car.

According to the dealer, the "Miles before service needed" that shows up when I start it is based on the number of cold starts, not just the number of miles actually driven.

I think this objection still misses the point. In my vector rotation example, a vector object's internal state is just three floating-point numbers. Even for this simple and well-understood object, "v.rotX( 30 ); v.rotY( 30 );" can give a different internal state than "v.rotY( 30 ); v.rotX( 30 );".

However, I do agree with you that it's easy for bad programmers to create objects that are counter-intuitive and difficult to understand. It's up to the programmer to insure that an object isn't encrusted with dozens of badly-thought-out methods with no obvious paradigm for how to use them.

Reply on news.ycombinator.com