CODEWITHSUNDEEP
javadata-structures
Jim_CS
Jim_CS

Reputation: 4172

Is there case for not using getters and setters here?

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?

Upvotes: 2

Views: 106

Answers (3)

yshavit
yshavit

Reputation: 43401

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.

Upvotes: 3

mikek3332002
mikek3332002

Reputation: 3562

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.

Upvotes: 1

Luchian Grigore
Luchian Grigore

Reputation: 258638

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.

Upvotes: 2

Related Questions