6 ms·

Disagreement about how to name methods is not an 'anti-pattern'. It's a literal non-issue that affects nothing at all whatsoever. Junior programmers pick on wh

Disagreement about how to name methods is not an 'anti-pattern'. It's a literal non-issue that affects nothing at all whatsoever. Junior programmers pick on whitespace formatting and variable names because that's the only kind of criticism their skill level allows.

ncmncm 7y ago
This is not about naming or formatting. This is about the prevalence of what are commonly called "setters and getters", that are a fairly reliable indicator of poorly thought-out design. You can learn something here, if you pay attention. In a sound design, objects more usually get their attributes at construction time, and keep them until they are destroyed. When something needs to change, from outside the object, it is usually better to make another object. Of course an object can still have mutable state, altered by member functions that do actual, useful work, but they have no use for setters and getters -- they have direct access to the member data that needs to change. The key here is that the public member functions should be doing useful work for you. Just mutating primitive state is noise. If the object doesn't abstract anything, it isn't earning it keep. Another indicator of bad design is public virtual functions.
- rootlocus 7y ago
  > 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.
mcbits 7y ago
It's not just the naming. It's the very existence of accessor methods/properties that are the anti-pattern, or at least code smell. At a minimum, they're as smelly as exposing the object's internal state to external manipulation directly through public fields, and it's even more of a red flag if the accessors are liars and do things beyond simply getting/setting field values. (Obvious exception for DTOs and such, if you don't consider those a problem.)

ncmncm 7y ago

This is not about naming or formatting. This is about the prevalence of what are commonly called "setters and getters", that are a fairly reliable indicator of poorly thought-out design. You can learn something here, if you pay attention. In a sound design, objects more usually get their attributes at construction time, and keep them until they are destroyed. When something needs to change, from outside the object, it is usually better to make another object. Of course an object can still have mutable state, altered by member functions that do actual, useful work, but they have no use for setters and getters -- they have direct access to the member data that needs to change. The key here is that the public member functions should be doing useful work for you. Just mutating primitive state is noise. If the object doesn't abstract anything, it isn't earning it keep. Another indicator of bad design is public virtual functions.

rootlocus 7y ago
> 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.

mcbits 7y ago

It's not just the naming. It's the very existence of accessor methods/properties that are the anti-pattern, or at least code smell. At a minimum, they're as smelly as exposing the object's internal state to external manipulation directly through public fields, and it's even more of a red flag if the accessors are liars and do things beyond simply getting/setting field values. (Obvious exception for DTOs and such, if you don't consider those a problem.)