Kieran's Programming Beginner Questions

[kieranmillar]

I'm trying to improve my coding style as I go along, and want to know people's opinions about getters and setters.

Data should be private. Helps with encapsulation. Makes a lot of sense.

But if you have a class or struct that only exists to group together some related data, say as some sort of class within a class, are a bunch of trival getters and setters all that useful?

After thinking about it, I can see the argument that using getters and setters is always a good idea, because it can help with future debugging or expanding functionality of the class, if every variable access or change must be done through a function, you have an easy way to add logging or change the way it happens later, rather than digging through code for everywhere where those values were altered directly.

But I also read people on the internet moan about having a bunch of trivial getters and setters, and that objects should be designed around having an API of what actions you want to perform that result in the data being changed, rather than ever just changing the values directly. This makes a lot of sense too.

But sometimes I just want a simple class or struct that just stores some related data, so I guess in this case direct access probably makes the most sense and getters and setters should be avoided? Does it matter? Reduces overhead maybe, I don't know.

I know programmers love nothing more than a good moan, so if you have any opinions, feel free to have a whine and help me learn!

[Colorful Arty]

Personally I find the whole make variables private but provide getters and setters to be rather stupid. If you're going to modify variables outside the class, why bother making them private?

[Simon]

The idea of OO is to encapsulate behavior and data.

Merely grouping data is handy, but it's distinct from an object in the sense of OO. It's Plain Old Data, and often appears in the belly of more complex classes, or as messages that you must send manually on a very low level between two OO-style objects, e.g., over a network connection.

If every possible state of your POD is legal, and modifications to single fields of the POD don't require checks to maintain some invariant, then go ahead and make all fields public. There are many other ways to keep this maintainable, e.g., you can restrict the use of this POD to a single part of your program.

When your objects have meaningful behavior, then exposing many getters and setters is a design smell. Your class should expose a meaningful high-level protocol. The principle in OO is Tell, Don't Ask: If class A must ask class B for some data to perform some logic, consider to move this logic into class B, and merely have class A tell class B to perform the logic.

-- Simon

[ccexplore]

There are definitely some cases where you are really dealing with POD (ie. Plain old data) and therefore should just do all public fields.  For example something like a Point that captures a pair of x and y coordinates.  But even examples that seem obviously POD (or started off as such) might end up evolving into something that's no longer POD.  For example maybe you want to represent a mutable (questionable design choice, but for sake of argument we'll allow it) complex number, which can be represented in Cartesian (ie. real and imaginary components) and polar forms (ie. magnitude and phase), and maybe you want to support the ability (also questionable design, but let's just say so for sake of example) for user to change any of the four properties and have the program automatically recompute the other properties based on the change.  In such a use case, the complex number is no longer POD, and moving to the property model with (now nontrivial) getters and setters becomes more sensible.