Usually, getters always return the value of a variable. I learned in my literature that access to fields is controlled by getters and setters. When I had my code rated by programmers, it was suddenly said that getters and setters violate object-oriented thinking.

So far, I have always set the output-statements in the method of a class that made changes to the object. However, if I want to change the way I make outputs (for example graphically or in a terminal), I would have to rewrite all classes. Therefore, I have considered doing the following: The output is no longer realized in the class, but the class provides methods that provide the values to be displayed. Another class is then created for display, which uses special getters to query the state of the object and display the data as it pleases. The getters are in the class that has this data. For example, I could have a "Human" object. The Human has amongst other things the variables lifeCurrent and lifeMax. These fields represent the health, if you set these values in relation. Another class called "Display" is now responsible for displaying the current health of a Human. So I would create a getter "getHealth" in the Human-Class that returns a list with lifeCurrent and lifeMax. the Display-class would have a function called health(Human). This function calls the getter from the Human and displays the values for the user of the program. Is it an accepted style to use getters like this?

2 Answers 2


The names you give to program entities shows what you think about them, and that doesn't seem to be straight (if I understand your description correctly):

  • Instances of Human represent human beings, and that's good.
  • A method getHealth() returning a list of lifeCurrent and lifeMax implies that a "health" is a pair of lifeCurrent and lifeMax. That's strange. To me, a health would be a number that can be calculated from lifeCurrent and lifeMax (if that's your model world's assumption). So, getHealth() should do that computation and return the result. [If you say "give me a car" to someone, you don't want to get a kit without instructions, you want the end product].
  • It's good to separate business logic and user interface, as you do it with Human (business logic) and Display (user interface).
  • A class name of Display confuses me. Class names should be nouns, so I'd read that as e.g. a TFT display, which is not what you meant. A better name would be Presenter. And different instances of Presenter might show the result on different media, or in different formats.
  • A method name of health(Human) is too unspecific. What does it do about the health? printHealth would be a better name. And I'd expect a printHealth() method to accept a health parameter (a number) instead of a Human. I'd expect a print method accepting a Human to print all information about that Human.
  • 2
    It pays not to make claims about things that are too strict. For example, the difference between Display and Presenter is not whether they are nouns, but that the latter has a suffix -er which implies an agent noun (and therefore implies something more about its particular role here). Also, I don't agree that printHealth(human) is less clear than printHealth(healthParameter), if printHealth belongs to a set of methods (such as a HumanPresenter) that operate on Humans. Nor must a Health be a single value rather than two - it would all depend, and may be printed as two values
    – Steve
    Commented Feb 3, 2018 at 14:09

Short answer is no. As soon you define any method that returns an instance variable in any form for the sole purpose of having that information on the other side, you are smearing responsibilities all over your application, violating encapsulation and all sorts of other things.

Now the question becomes: Do you have a reason to invite all those bad things? If yes, then there might be a reason to have getters too.

One of the reasons could be that you have a natural boundary (of the business domain), and you don't (can't!) know what happens on the other side. So, if you don't know how it will be displayed by some other developers, then you need to publish all the data. If you do know how it will be presented, then that presentation (an abstract part of it) belongs in the object (as to avoid getters).

So the question is, why do you want to change the output method. Is it really a requirement to be able to change it any time? Or will it be changed one time and probably never again?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.