> You can learn something here, if you pay attention. I'm all for learning and debating, but this comes off awfully patronizing. > In a sound design, objects

> You can learn something here, if you pay attention. I'm all for learning and debating, but this comes off awfully patronizing. > In a sound design, objects more usually get their attributes at construction time, and keep them until they are destroyed. Immutable objects are nice and I always try to use them when I can, but arguing that everything should be immutable or you have a design problem... that's exaggerated. > When something needs to change, from outside the object, it is usually better to make another object. As with everything, there's a trade-off with any solution. Allocating and copying data isn't cheap. And the fact that you just pick one way of doing things and discard anything else as "bad design" doesn't inspire confidence. > The key here is that the public member functions should be doing useful work for you. No, the "key" is that you are abstracting access to data. Your setter may do validation or transformation on the data. You may only offer const access to data. You may even do a defensive copy of the data. You may set breakpoints or log access to the data. > If the object doesn't abstract anything, it isn't earning it keep. Not all objects need to represent functionality. Some represent data. And mutating data is fundamentally what every program does. Just because you have an aversion to mutating data outside your object and you are willing to pay the price for immutable structures, doesn't mean everyone else is following a "classic anti-pattern". > Another indicator of bad design is public virtual functions. I really don't see the wisdom behind this one.