patternjavaMinor
Java beans performance with object inside object
Viewed 0 times
withjavabeansperformanceobjectinside
Problem
I am developing a bean class which has multi face properties (name has first name, last name and middle name). The object is going to be used to create an xml file. Please compare my two methods to incorporate the same in my application.
Method 1:
Method 2:
Note: Above is just a sample. The requirement is to group a set of properties. In Which way of the above performance/code standards will be good?
Method 1:
public class SampleVO {
String firstName;
String middleName;
String lastName;
// getters and setters
}Method 2:
//Main object
public class SampleVO1 {
NameVO name = new NameVO();
// getters and setters
}
//Name object
public class NameVO {
String firstName;
String middleName;
String lastName;
// getters and setters
}Note: Above is just a sample. The requirement is to group a set of properties. In Which way of the above performance/code standards will be good?
Solution
From a performance perspective both approaches are comparable. Yes, method 2 will use some additional memory and require a few more instructions for instantiating your
From a coding standards perspective, method 2 is superior over method 1. In general, composite values (such as names) deserve their own object.
First of all, it allows you to add additional methods in your
Secondly, it gives you the option to reuse
Thirdly, if your code uses validation, you can decouple the validation of the contents of a name from the validation of the existence of a name.
Furthermore, by adding an
As an aside, I would even go so far as to suggest a slightly modified version of your method 2:
This effectively makes your
NameVO, but unless you're dealing with millions of objects, I would not worry too much about that. From a coding standards perspective, method 2 is superior over method 1. In general, composite values (such as names) deserve their own object.
First of all, it allows you to add additional methods in your
NameVO, such as the likely String getFullName(), which handles the possibility of having null as a middleName. This also gives you the flexibility to change the contents of a NameVO later on, for example by adding initials, salutations, etc. Secondly, it gives you the option to reuse
NameVO in other contexts. For example, you could have a Customer object with a name field, and a Supplier with a name field, etc.Thirdly, if your code uses validation, you can decouple the validation of the contents of a name from the validation of the existence of a name.
Furthermore, by adding an
equals and hashCode, you also gain the possibility to store your objects in a Map, indexed by NameVO. As an aside, I would even go so far as to suggest a slightly modified version of your method 2:
public class SampleVO {
NameVO name;
// getters and setters
}
//Name object
public class NameVO {
final String firstName;
final String middleName;
final String lastName;
public NameVO(String firstName, String middleName, String lastName) {
// assignments
}
// getters
}This effectively makes your
NameVO immutable, making it more suitable for use as a key in a Map. It also makes it safer to pass NameVO objects around without having to fear side effects.Code Snippets
public class SampleVO {
NameVO name;
// getters and setters
}
//Name object
public class NameVO {
final String firstName;
final String middleName;
final String lastName;
public NameVO(String firstName, String middleName, String lastName) {
// assignments
}
// getters
}Context
StackExchange Code Review Q#35591, answer score: 6
Revisions (0)
No revisions yet.