Java: how to deal with a lot of fields and their encapsulation?

Suppose my task is to code a role - playing game This means, for example, I want to track a character in a role game and its statistics, such as intelligence, damage bonus or life point

I'm very afraid that before the end of the project, I may eventually deal with a lot of areas - for each area, I have to make sure that they follow very similar constraints and behaviors (for example, I want them to have a boundary between minimum and maximum values; I want to be able to distinguish between "basic value" and "temporary bonus"; I want to be able to increase and decrease both without passing through a setter and smoker) Suddenly, for each field, I need one (two) getter and four setters, and I may need several resets! Even in 10 areas, this means that many methods are the same, eek

For dryness, I have started to encapsulate the logic that confuses these statistics in the field class, so I can write such as Intel Applybonus (10) or hitpoints Code like get () (it cares about the return value in the range) and so on. I've even gone so long to set up courses in these fields, but now it's not

Now, I encounter this problem when "inserting" fields into gamecharacter: most Java textbooks say that each class should have private fields of public getters and setters This sounds good in theory, and I've built an entire class around int; However, when you find yourself calling a getter to get a getter, the idea doesn't sound so solid:

thisCharacter.getIntelligence().get() //eeek

I prefer to access this field directly Maybe this is my Python / VB [1] "background", but for me, it is cleaner, clearer and more direct:

thisCharacter.intelligence.get()

The problem in the public domain is that I give up all control; For example, somewhere else in the code base, unfortunately, the following may happen:

thisCharacter.intelligence = somethingThatReallyIsNull;

Sounds like a subtle mistake... But I mean, do I really have to worry? I have never planned to directly allocate fields [2]. I have recorded in Javadoc that this is not the right thing to do, but I am still new, so I am a little torn up

So I'd like to hear your views on this topic The advantages of packaging are so great that I should move forward, smokers and smokers, etc., or should I take health measures to package and make the field a public domain?

[1] Yes, I know I've been trying to forget But recently we have just seen some c# and people, not material sweetness ok

[2] Except constructors! A getter won't save me from a wrong constructor

Solution

My experience is that when a large number of fields are needed, the number, nature, naming and type of fields are very flexible and may change throughout the life cycle of the project, so you may need some kind of map instead of fields

For example, there is an attribute mapping from key to value

Provide public phones to get and set properties, but don't let everyone use them (or make sure they don't) Instead, create a class to represent each property you are interested in, and the class provides all the functions for manipulating the property For example, if you have strength, you can have a "strengthmanipulation" class initialized to a specific player object, and then provide getters and setters (all with appropriate validation and exceptions), perhaps like calculating strength and bonuses

One advantage is that you can separate your properties from the use of the player class So if you add an intelligence attribute now, you don't need to process and recompile all intensity only operations

This is a bad idea for direct access to fields When you access a field in VB (at least in old VB), you usually call a property getter and setter, and VB will hide () calls for you My view is that you must adapt to the language conventions you use In C, C, Java, etc., you have fields and methods Calling a method should always have () to make it clear that it is a call, and other things may happen (for example, you may get an exception) Either way, one of the benefits of Java is that its syntax and style are more precise

VB to Java or C is like texting graduate science writing

BTW: some usability studies have shown that if they are needed, it is best not to add parameters to the constructor, but to construct and call all setters