Better way to store a massive amount of variables

Newbie & Debugging Questions
#1

At work we have a class that is essentially a large class containing a private variable with corresponding getter and setter functions. Now, in the beginning this wasn’t a problem; only 4 or 5 members in this class and it was maintainable and easy to modify. That is not the case now. I just had to go add a new member to the class and was forced to look at the ugly mess of code in that file and I finally though “enough is enough”. So now I’m trying to think of a better way to store these variables.

For instance, in C# we have ‘inline’ getter and setter functions:

private string variable { get; set; }

That’s awesome. Obviously Java has nothing like this, but I’m still trying to find a way to reduce the lines of code one needs to type to just add one variable to a class.

Theoretically I could use a map of some sort, but I feel that’s overkill for something as simple as this. Is there some kind of design pattern I’m missing? I just want to find a way to easily declare a variable that will be accessed only once per instance without the clutter and mess of those getter and setter functions. This is kind of a noob question, but there has to be a more dynamic way, right?

Right?

#2

Use a dot. That’s what it’s for.

Seriously, if you’re just using this class as some sort of bucket for what amounts to global variables, you’re possibly getting your design all muddled anyway. Perhaps you might consider breaking up the class into separate concerns.

Cas :slight_smile:

#3

Unfortunately the company insists on using private variables and this is a “payload” class containing any relevant variable to the web application we are working on. Splitting it into classes may actually muddle our design more, which is why I’m in a predicament. Oh well, I might just have to suck it up.

#4

Why would you think added complexity would be a better option. Set aside your sense of aesthetics when it comes to the code in the IDE and realize that the compiled code is what’s important. Adding extra operations to the processors workload to make things prettier in the editor isn’t really a great trade-off. Depending on the application, the extra overhead may not make much of a difference, but you still need to consider that someone other than you may potentially have to maintain the code somewhere down the line. I’m sure they won’t be a fan of added complexity either. :wink:

There are multiple better ways to approach this. Netbeans, the IDE I use, has built in functionality to generate standard getters and setters with just a few clicks of the mouse. I can’t imagine it’s unique in this respect. Code can also be “collapsed” in the IDE reducing visual clutter considerably. There are also numerous “beautification” tools to handle code formatting.

The old school approach is to just make variables public when it makes sense and get rid of un-needed getters and setters. I always go with the rule of thumb that unless I’m doing some sort of extra processing when a value is assigned to a variable in my class (such as setting other dependent variables or performing sanity checks), it’s safe to have the variable public. There is no practical difference in encapsulation between this:


public class MyClass {
    protected int foo;
    
    ...

    public void setFoo(int foo) { this.foo = foo; }
    public int getFoo() { return this.foo; }
}

and this:


public class MyClass {
    public int foo;
}

Edit:
(Just saw you posted this)

Just go with refactoring tools then. Let the IDE do the work instead of typing out getters and setters by hand. :point:

#5

Sure, I don’t want to make it more complex than it already is. It’s definitely less about the aesthetics of the code and more about how damn messy it’s getting. I don’t care what it looks like, I just care that the class is soon going to be a couple hundred lines of code just because there does not seem to be a more friendly way to do this. Sure, I could “minify” the getter and setter functions and save a few lines of code but… I don’t know. This was a silly question, I was just suddenly horrified by the long list of variables and accessor functions that I have created.

#6

What exactly is messy about it? Isn’t it just a bunch of variables and then getters and setters?

Sure, that’s not ideal (http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html, http://stackoverflow.com/questions/9416245/how-to-avoid-getters-and-setters, http://programmers.stackexchange.com/questions/21802/when-are-getters-and-setters-justified), but it’s a pretty standard paradigm.

You could try to split it up into multiple classes, or a hierarchy of classes.

You could try to use a Map or a Properties object. Look at how the Calendar class handles their getters and setters: get(field); set(field, value).

You could just make the variables public and get rid of the getters and setters.

These are all valid options, but it depends on your exact context. Many contexts are expecting Java beans, so you might be out of luck. You’re better off spending your time getting over it and figuring out IDE tricks around it (generating source) instead.

#7

I know how to generate the getter and setter functions. Thanks for the links, I think I’m just going to take everyone’s advice and suck it up for now. Next project I’ll try to plan it out better!

#8

Clutter and messy code are perfectly normal characteristics of Java business applications any large grown application.
So nothing to worry about. ;D

#9

I also had to smile at the “couple hundred lines of code” comment. I’m on two big projects at work, let me see how big each of their main classes is… one is 1398 lines of code, the other is 4966 lines of code.

That’s not GOOD by any means, but my point is that “production code” doesn’t always live up to academic goals. A couple hundred lines of getters and setters in a Java bean? I wouldn’t worry too much about it.

#10

Oh I’ve seen some of our core framework code… it’s terribly long and ancient. My small payload class by comparison is not bad at all, I was just hoping to find a way to make everything more dynamic and compact. I still have a lot to learn I see :wink:

#11

Evil suggestion. If access times aren’t important them put the variables into a map. This is easy if there’s not work being performed inside get/set methods.

#12

Shouldn’t access times of a Map be pretty much O(1)?

The real evil is that it’s going to take so much more memory, and break the Java Beaniness of the class.

#13

Yes, but Roquen is all about those constant factors. :wink:

#14

Memory stalls are a pretty big constant. Another option is to use annotations to automatically weave get/set methods. What’s the lib that has that kinda stuff? Humm…it’ll come to me.

#15

Project Lombok.

#16

IMO: Personally i use this Pattern to organize code - don’t like files with 5k+ lines ^^
(because not find nothing better)


_Frame_Tab_0_Data //Hold only Variables and primitive get set
_Frame_Tab_01_Save
_Frame_Tab_1_F_Base
_Frame_Tab_2_F_Add
_Frame_Tab_3_F_Top
Frame_Tab //top class hold public constructors

but its creates many small files )

(sad that java don’t have multiple class extension - but not so critical)

p,s yes, it’s be cool use Map for variables, but performance, memory, direct links - omg,
Dot class - hard to read code :frowning:

#17

Few hundred lines of code of getters and setters is messy? At my work there is a C++ class, and the header is like 800 lines of code, while the implementation is like 5k or even more. It is pretty much a getter setter class, but I guess you would call it whole other level. I wouldn’t call it hard to maintain, because all it is one huge file and nothing more. If you actually need to add / modify something, you are only probably going to look at functions that are no more than 50 lines of code.

There is another class though which is also like 5k lines of code. That class is impossible to maintain if you happen to need to edit something that you shouldn’t have. If after you edited something you start getting assserts (thank God at least the class has some of those), you can prepare to go on a long hours journey fixing code that was written assuming no one would ever again touch it. All the code is spaghetti and all the functions depend too much on each other, so in the end it seems like it is few very very big function, even though it has like 100 functions. It has all kinds of code - 2D point path to 3D point path generation, economy logic that is associated with that class and much much more that I’m not sure how to describe. Long story short is should have been long split up into many smaller classes.

#18

Yeah that’s what I was think of.

#19

Eclipse can autogenerate getters and setters for you if that helps…

#20

Do you really need to preserve the beanness? I mean do we use beans anymore? Well not much. But there is a reason for getters and setters for a class. Inevitably these methods end up doing more that set a variable.

Personally unless there is a real reason to have it as a bean, i would use a map. I would also worry about performance if or when it became an issue.