byte short int long float double boolean charThese primitives can be considered to be the building blocks for all other value objects within Java and allow users to hold data as fields and variables. However, I would argue that they are not useful and a good rule of thumb is to not use them at all. Instead Java provides the classes:
Byte Short Integer Long Float Double Boolean CharacterThese are classes for fully fledged, immutable, value objects which can be used in much the same way as the basic primitives, but offer the following advantages:
1. They can be used in generics. This is possible:
new ArrayList<Integer>();But this is not:
new ArrayList<int>();2. They can still be passed into library functions that demand primitives. Auto boxing means that a method signature with
int can still be called with an Integer objects transparently. Likewise, a function returning an int can be assigned to an Integer.3. They offer all the expected methods for use in debugging and collection handling, such as
toString, equals and hashcode.4. They can be null. While there is a lot of discussion as to whether applications should be passing null around, it is still sensible to ask the question what should be returned from a method such as
getIdIfPresent if there is no ID. With primitives, you'd be forced to return a value that represented a nonexistent result, such as -1. WIth real objects, you have the option of returning null.5. Primitives in java are passed by value, whereas objects in java are passed by reference. This may not have a huge impact on how you would handle
Integer vs int, however. This is because the objects that represent the primitive types are immutable, and therefore you cannot change the value of any of the parameters passed. Despite this, I would recommend using objects over primitives, simply because it means you don't have two kinds of behaviour represented in your code.
4 comments:
hey buddy, your first example on generics has the same line of code 'new ArrayList()' for both cases. Not sure if you meant it that way?
Crap. Looks like the editor removed the angle brackets first time. Should be fixed now.
You leave out the cons to using boxed types though. For example, (1) auto-unboxing can be a performance drain, (2) you could potentially run into some NPEs that you weren't expecting by passing null value boxed types into something expecting primitives, etc.
True. I hadn't considered the performance drain around auto-unboxing. And given that java doesn't support nice nulls like languages such as ruby, NPEs are definitely a problem.
Having said that, I would offer the following responses to those two points:
When writing software, performance is definitely a concern, but when developing code that has to be maintained by others, readability and ease of change is king. Prematurely optimising code for performance often impacts this negatively, and the performance drains associated with auto-unboxing will probably cost much less in terms of hardware than any gains from improved maintainability.
The second point of potential NPEs highlights the problems associated with passing nulls around in general. While I think it would be better for a method called getIdIfPresent to return null instead of -1 in the case where no ID is found, I do think passing null around is still generally a bad idea. Even better solutions to this problem would be to return an Option wrapping an integer. Another alternative is to start using microtypes, using a small class to represent IDs rather than integers or strings. Such a microtype could have validity checking instance methods, or have the behaviour for unfound IDs driven into it.
Another possible drawback of not using primitives is while:
int x = 1;
int y = 1;
return x == y;
returns true, this:
Integer x = 1;
Integer y = 1;
return x == y;
returns false. This is because the == operator works with values with primitives and references with objects. However, forcing yourself to stick purely to the equals provided by object classes can be considered a good thing, as it maintains consistency in your code.
Post a Comment