4 ms·

IMHO getters & setters can be a bad smell, symptomatic of classes that are just dumb aggregations of data that have no significant behaviour. I've seen them mos

IMHO getters & setters can be a bad smell, symptomatic of classes that are just dumb aggregations of data that have no significant behaviour. I've seen them most often in Java - a single paradigm lang that forces every method or data item to be a class member. And then, because our data item is a class member, it must be encapsulated. Multi paradigm langs offer better approaches to data aggregations. Python, for instance, gives us dictionaries and named tuples as well as classes.

larzang 9y ago
Generic data types aren't necessarily a better approach. My primary language for many years has been PHP, where the default approach used to be just to pass generic maps around for all data, and it was hell. You cannot tell if a map passed to you has any of the members you expect, hasn't had additional unexpected members added, or anything else about it without parsing it, it's a mystery bag. There are times when a mystery bag is fine and you're going to be inspecting it anyway, but most of the time your code has at least some expectations about the structure of your data, and for that you need real specific types to maintain any kind of sanity. Otherwise, you're re-validating data over and over or writing code that relies on hope and faith instead of correctness.
- spdionis 9y ago
  Why use actual objects and rely on static anlysis when you can write tens of unit tests that ensure the maps/tuples passed around always contain the correct data structures? And you get the added benefit of 100% test coverage.
  - gruez 9y ago
    now you have to add (manual) type checks in your tests instead of your compiler doing it for you
    - spdionis 9y ago
      You probably didn't get the sarcasm :).
spdionis 9y ago
> dumb aggregations of data that have no significant behaviour. The horror... /s
- ninkendo 9y ago
  I think the point is that dumb data structures should look like dumb data structures, with a language construct like `struct`, rather than trying to defensively put everything as a getter/setter because “maybe this won’t be a dumb struct in the future” or something. Such a thing does reek of design smell to me, and is a sign that you’re blending your data and your logic too much.
  - spdionis 9y ago
    The problem with a struct-like construct is that it doesn't have any way of guaranteeing some data is present and valid or not. I'm thinking about C++-like structs or python maps. An object representing a dumb data structure can be written in order to have many useful guarantees upon construction, for example making it impossible for the object to be created without fully initializing it, or guaranteeing the presence of all "keys" in the structure. This is easily guaranteed statically and it's so damn useful!
    - ninkendo 9y ago
      I appreciate what you're saying, and I agree that it's a valid approach, but I would be more interested in making any of the methods which are interested in the object, capable of handling any of the values expressible by the object's type. That is, you need useful zero values (which means no null pointers), and any method that takes the object should be able to do sensible (if not useful) things even if things are their zero-values. As for validation, you don't always know what different consumers of your type consider to be valid or not. For a rectangle any non-negative size should be valid, for instance, but when you try to pass a zero-sized x side to a class that (for some reason) needs non-zero x length, that class should be doing the validation, not the Rectangle class itself. I think I'm coming at this after doing nothing but golang for a few years, and then having to switch to Java recently, and I really hate the language so far, mostly because of the style of programming it encourages.

larzang 9y ago

Generic data types aren't necessarily a better approach. My primary language for many years has been PHP, where the default approach used to be just to pass generic maps around for all data, and it was hell. You cannot tell if a map passed to you has any of the members you expect, hasn't had additional unexpected members added, or anything else about it without parsing it, it's a mystery bag. There are times when a mystery bag is fine and you're going to be inspecting it anyway, but most of the time your code has at least some expectations about the structure of your data, and for that you need real specific types to maintain any kind of sanity. Otherwise, you're re-validating data over and over or writing code that relies on hope and faith instead of correctness.

spdionis 9y ago
Why use actual objects and rely on static anlysis when you can write tens of unit tests that ensure the maps/tuples passed around always contain the correct data structures? And you get the added benefit of 100% test coverage.
- gruez 9y ago
  now you have to add (manual) type checks in your tests instead of your compiler doing it for you
  - spdionis 9y ago
    You probably didn't get the sarcasm :).

spdionis 9y ago

> dumb aggregations of data that have no significant behaviour. The horror... /s

ninkendo 9y ago
I think the point is that dumb data structures should look like dumb data structures, with a language construct like `struct`, rather than trying to defensively put everything as a getter/setter because “maybe this won’t be a dumb struct in the future” or something. Such a thing does reek of design smell to me, and is a sign that you’re blending your data and your logic too much.
- spdionis 9y ago
  The problem with a struct-like construct is that it doesn't have any way of guaranteeing some data is present and valid or not. I'm thinking about C++-like structs or python maps. An object representing a dumb data structure can be written in order to have many useful guarantees upon construction, for example making it impossible for the object to be created without fully initializing it, or guaranteeing the presence of all "keys" in the structure. This is easily guaranteed statically and it's so damn useful!
  - ninkendo 9y ago
    I appreciate what you're saying, and I agree that it's a valid approach, but I would be more interested in making any of the methods which are interested in the object, capable of handling any of the values expressible by the object's type. That is, you need useful zero values (which means no null pointers), and any method that takes the object should be able to do sensible (if not useful) things even if things are their zero-values. As for validation, you don't always know what different consumers of your type consider to be valid or not. For a rectangle any non-negative size should be valid, for instance, but when you try to pass a zero-sized x side to a class that (for some reason) needs non-zero x length, that class should be doing the validation, not the Rectangle class itself. I think I'm coming at this after doing nothing but golang for a few years, and then having to switch to Java recently, and I really hate the language so far, mostly because of the style of programming it encourages.