Is there case for not using getters and setters here?

Question

From what I understand, getters and setters are recommended for use for ALL variables and situations.

However I have a situation here where it seems they are just making the code long and awkward so I want to know can I leave them out in this situation or is that bad practise...

I have the following class -

public class Conversation {

    class Message
    {
        private int id;
        private int senderId;
        private Timestamp timeSent;
        private String text;
    }

    private int conversationId;
    private int userIdA;
    private int userIdB;
    private ArrayList<Message> messages = new ArrayList<Message>();
...
... (Getters and setters for members of Conversation)
...
}

So I am using getters and setters for the Conversation member variables. However I don't want to use them for inner class, Message, variables. It is just adding about 30 lines to the code of filler and makes it look much more awkward. So is it bad practise to leave them out here? I will also never be editing the Message variables, they will be set with a call to the constructor Message(..., ..., ..., ...) and after that they will just be read. So I definitely reckon it's fine to leave out the getters, but what about the setters?

http://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil — assylias, Mar 13 '12 at 23:31
Also, if you are going to use the Message class only in the Conversation class, you can declare Message private and omit any access modifiers inside the Message class. — Jakub Zaverka, Mar 13 '12 at 23:32
IF you do as Jakub Zaverka suggests (which in my opinion is a good idea), then setters would cause a compile time error. The compiler is strongly suggesting the answer to you. — emory, Mar 13 '12 at 23:33

yshavit · Accepted Answer · 2012-03-14T01:20:43.870

If Message were private, I would say no problem at all with using the fields directly; it's just an internal-details struct, and there are no encapsulation issues (since the outer class can see all of the inner class' private variables, anyway).

But, Message is package-private: anyone in that package can also see its fields. This is a gray area, because it's not quite the published API, but it's still reasonable, depending on how big the package is, that you'll want encapsulation down the line. For instance, if it's a big package and some other class starts depending on Message (and if none do, you may as well make it private), then you risk encapsulation problems if you want to change Message's internals down the line. So, it's a judgement call.

If Message were public, I would definitely say to provide getters.

Btw, if you're using Message just as a POD here, you should make it static -- good habit to get into. Generally speaking, static is better than not.

score 2 · Answer 2 · answered Mar 13 '12 at 23:32

getters and setters are recommended for use for ALL variables and situations.

Well, all never and always rules are bad. Excluding this one. :)

You shouldn't use getters and setters just because it's standard practice. For example, if I had a class Point2d with 2 members x and y, I'd probably not use accessors.

You should ask yourself - will my members be changed a lot inside the code? Will it be a hassle debugging and seeing where I change the members? If the answer is yes, you definitely need accessors. If not, it's up to debate - whatever makes the code more readable and easy to maintain.

I'm gonna steal your first line for my programming courses. :) — madth3, Mar 13 '12 at 23:45

score 1 · Answer 3 · answered Mar 13 '12 at 23:36

1

If they are set in

new Message(int,int,Timestamp, String)

and the fields won't be changed then it is best have get methods only.

Only having get methods helps enforces your constraint of making them read only.

answered Mar 13 '12 at 23:36

mikek3332002

3,546
4
37
47

Is there case for not using getters and setters here?

3 Answers3