2

as you can see the class below declares 2 private instance variables and 2 get & 2 set methods associated with each private member to allow for manipulation and validation of them.

My question is: which is better to use in the constructor deceleration, the instance variables directly as shown in the snippet below or to use the set methods associated with them and also which is promote good software practices to use in the toString method, the instance variables or their getter methods?

thank you for your time.

public Class Employee { private String firstName; private String lastName; public Employee (String first, String last) { firstName = first; lastName = last; }//end of constructor public void setFirstName(String first) { firstName = first; }//end of method setFirstName public String getFirstName() { return firstName; } public void setLastName(String last) { lastName = last; }//end of method setLastName public String getLastName() { return lastName; }//end of method getLastName public String toString() { return String.format ("%s: %s %s\n", "Employee Name: ", firstName, lastName); }//end of method toString }//end of class Employee 

5 Answers 5

5

I tend to favour initialisation via construction. By using this method and providing appropriate checks (compilation time via final and runtime via null checks or similar) you can ensure your object is properly and completely instantiated.

Using the final keyword on your fields will make the compiler check that you've assigned a value to that field upon construction. It does mean that field is immutable, but it's surprising how often you require that.

I would be careful with providing getters for everything. If you're continually providing and using getters, that suggests that you're pulling data out of your object and manipulating it outside that object. Remember - a key principle of OO is getting objects to do things for you, rather than asking them for data and doing it yourself.

Sign up to request clarification or add additional context in comments.

2 Comments

Other than that, as a rule of thumb, using overridable methods in a constructor is discouraged as it makes code completely unmaintainable (at least in those cases that I encountered yet..)
Thank you Brian for your time and explanation. it is helpful.
2

Rule #1, always limit the access to the least necessary, i.e. unless you explicitly need to change the values of the first/last names, make the object immutable (constructor with parameters, no setters only getters)

1 Comment

Good rule, but I'd say this is besides the point in this case.
1

In general I tend to avoid calling non-static methods from the constructor (since the object isn't fully initialized at that stage). If the setter methods only sets a field to the parameter value, like above, I'd just set it in the constructor (i.e. not call the setter). If the setter is more complex, I'd try to factor out the logic to a static helper method, and use it both from the constructor and the setter methods. Something like:

 int field_; Constructor(int initialValue) { field_ = helper(initialValue); } public void setField(int value) { field_ = helper(value); } // not really complex, but avoid duplication of logic private static int helper(int value) { return 2*value; } 

Comments

1

If you expect your class to be extended (and the getter/setter overridden), it is best to use the methods instead of the variables.

NOTE: I'm not sure what happens exactly in the constructor, you are probably better off setting the variable directly.

You can mark the getter/setter as final and then you don't have to worry about overrides. Still a good practice to use those methods instead of direct access as you can put breakpoints or debug statements there more easily

2 Comments

Thank you Attila for your answer !! might throw another question to you - in terms of validation of Strings - from you experience what are the things you look for to validate strings in your code !! thank you again.
What are you trying to validate for? BTW, you might be better off posting this as a new question, with a more ellaborate explanation on what you are trying to achieve
0

I would use the setter. Sometimes you have extra code in the setters. For example, the setter for a list might also hook the list's Changed event, and by not using the setter, you will not capture the Changed event.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.