Hacker News Reader

Comment by gdp | Hacker News Reader

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.

View on HN

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

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.

> 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.

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