4

This question is not Java specific, however the code examples are in Java.

Sometimes you encounter very simple objects, like the following code:

public class Coordinates {
    private int x;
    private int y;

    public Coordinates (int x, int y) {
        this.x = x;
        this.y = y;
    }

    public void setX (int x) { this.x = x; }
    public void setY (int y) { this.y = y; }
    public int  getX ()        { return x; }
    public int  getY ()        { return y; }
}

I would say it would be much more efficient to access fields directly rather than through methods. Plus, the code would look simpler. The use itself would be simpler, and the class definition would be free of (unnecessary boiler-plate code) 4 methods than don't really do anything. (In a way I'm thinking of a use similar to struct in C or record in Pascal.)

The way I would do it is probably like this:

public class Coordinates {
    public int x;
    public int y;

    public Coordinates (int x, int y) {
        this.x = x;
        this.y = y;
    }
}

So why does the first way seem preferred? It feels like forcing something into becoming an object. It is just values bunched together into one variable, why using OOP just for the sake of it? True, I have kept the constructor. It is actually handy for when values are initially assigned, but there really is no need for other methods, except maybe a method set that sets both fields (like the constructor).

I know OOP is handy for many things, but to me this doesn't seem to be one of them. Am I wrong thinking like that?

Heimdall
  • 217
  • 2
  • 9
  • do read about `access specifiers` in java and oop principal `Encapsulation` you'll get your answer – amit bhardwaj Nov 13 '14 at 11:14
  • 2
    Long story short: because things change, and when the time comes and you need to add behaviour/validation, you'll need to create setters and getters. And if by that time there are 30 other applications using your library and calling your public fields directly, well, good luck refactoring all those applications. – dcastro Nov 13 '14 at 11:15
  • 1
    What @dcastro said was the reason I always was using getters and setters. But then when you think of it, you are most likely to write an end application, upon which no other app depend on. My most coding is directed into game development, and having public x, y, spd and whats not on each object is so much clear and easy to work with. – Coderino Javarino Nov 13 '14 at 11:18
  • You are free to design your code in whatever way you want - the only one that realy has arguments against your plans is the compiler. However note that with above aproach you leave the world of OO and go more into whatever principles scripting has to offer. – JBA Nov 13 '14 at 11:18
  • @CoderinoJavarino Even if you're writing an end application, there can be 30 other classes inside that application using your type. – dcastro Nov 13 '14 at 11:18
  • 2
    +1 for the points so far. One further point though, remember that in Java at least setters and getters are often inlined. Thus there is no performance cost for them as they become the equivalent of exposing the fields directly but without the maintenance trade off. – Chris K Nov 13 '14 at 11:19
  • 1
    That being said - there are cases when you know you won't need getters/setters. The example provided by @Heimdall is actually a good one. The classic example is the class `Point` with `x` and `y` fields. A point, by definition, could have any `x` and `y` coordinates, so it's *veeeery* unlikely you'll need to add validation in the future. – dcastro Nov 13 '14 at 11:22
  • 1
    Flexibility &Maintainability: If today you don't think you really need validation or processing of the data, good Object Oriented design ensures that you plan for the future. – Sagar Pudi Nov 13 '14 at 11:31
  • Thank you for your thoughts. I didn't know the term "getter" and "setter", otherwise I would have probably noticed the duplicity myself. I understand pro-getter-setter arguments, but if a class has a very limited use in either end application or if it is a private inner class, I would think my arguments for public fields prevail. – Heimdall Nov 13 '14 at 11:53

2 Answers2

0

No one is forcing programmers to define the 4 getters/setters. If you like, you can make the 2 fields public and respectively define no getters/setters.

But you have to make sure that in the future the original idea behind this will stay the same i.e. that no one will ever need non-trivial getters/setters. If that's the case, you're fine to make the fields public and access them directly.

peter.petrov
  • 38,363
  • 16
  • 94
  • 159
0

Off the top of my head, there are a few reasons:

(1) Convention - when I have an object from a library that I am not familiar with, when do .get my IDE is effectively providing me a list of properties. If I am working in a libary that I am not hugely familiar with, that can be an advantage.

(2) Serialisation - many libraries, such as the Jackson Framework, use beans as a standard. The framework then decides what properties an object has by looking at the methods which start get or set. Obviously, this is not a hard constraint, but it is convenient.

(3) Concurrency - Exposing the property directly relies on the client to make the object thread safe. If I have getter and setters, then I can ensure that they use appropriate synchronisation. Thus I can guarantee the thread safety of my object. Clearly, its better for the object to implement its own thread safety rather than to rely on the client. When I first write an object, I might not know in advance if I should implement thread safety.

(4) Maintainability - you might want to add extra logic to your getters or setters at some point in the future.

phil_20686
  • 4,000
  • 21
  • 38