If we re-execute our application with a null SecurityTransactionRepository object passed to the SecurityManager constructor, our call to the findTransactionById method now results in an empty Optional object. This downcasting is common when implementing the equals method in a custom class: In many cases, instanceof is used to safely convert an object of a known supertype into an object of the desired subtype (called downcasting). It is likely a sign that we are skipping strict type-checking (and therefore losing the benefits of the Java type-checking system).
#JAVA DOWNCAST CODE#
While there are cases (especially when working with low-level code or when using reflection) that instanceof may be necessary, it should be treated as a code smell. Similar to valueOf, the instanceof keyword provides an opportunity to circumvent the type-checking system of the Java compiler. Their inclusion in an application should be considered a code smell and is indicative that we have a String that should be represented by another data type. Therefore, when possible, we should avoid using valueOf methods that convert a String to some primitive value, including: Notice, though, we have to make a conscious decision about what value to set accountValue to when a non- long is provided, even though one should never be provided in the first place. Instead, we should change our JSON to properly represent our intent: The type of our accountValue field is a String, and nothing stops a user that is unfamiliar with our application from rightly setting accountValue to a String.
We would be wrong for thinking that, though, since nowhere in our JSON or even in our code is it documented that a long is expected. We may be tempted to think that this is not possible since everyone must surely know that an account value is a number. Instead of allowing the compiler to perform static type-checking analysis on the source code of our program, we have instead deferred this check to runtime, where Long.valueOf is now responsible for implementing the type-checking.Įven if we attempt to catch this NumberFormatException in our getAccountValue method, we are now responsible for deciding on what to do when we encounter a number that is not a convertible to a long. Instead, during execution, an exception was thrown when "unknown" was passed to Long.valueOf, causing our application to abruptly exit.ĭue to our decision to represent accountValue as a String, we have now delayed our type checking from compile-time to runtime. It is crucial to note that this exception occurs at runtime, not compile-time: The compiler did not have enough information during compilation to deduce that the value provided to Long.valueOf was not going to be a String that it could safely convert to a long. For example, we can define an Address class and instantiate a variable with a specific Address state: With the introduction of Object-Oriented Programming (OOP), we can define new natures by creating classes and instantiating objects of that class. By applying a type to every piece of data, we make an explicit statement about the nature of that data.įor example, if we define a variable as having a type of int, we state that the variable cannot be larger than 2 31 - 1 and cannot be less -2 31. One of the most significant benefits of strongly-typed languages like Java is that the compiler can enforce our intentions at compile-time. Yet 4 More Techniques for Writing Better Java.4 More Techniques for Writing Better Java.
#JAVA DOWNCAST SERIES#
The interested reader is encouraged to check out the other articles in this series to learn 12 more ways to utilize the Java language to solve problems more effectively: Lastly, we will look at when and where to throw exceptions for maximum effectiveness and how throwing an exception in the correct place can make the difference between a well-designed class and a debugging nightmare.
#JAVA DOWNCAST HOW TO#
Next, we will follow the same train of thought and explore the instanceof keyword and how to avoid abusing this feature. First, we will take a look at the valueOf methods provided by the box primitive types and how to avoid these methods whenever possible. In this entry in the Techniques for Writing Better Java series, we will delve into three often-overlooked aspects of the Java language. You may also like: 4 Techniques for Writing Better Java
#JAVA DOWNCAST PROFESSIONAL#
Just like a woodworker understands the nuances of his chisel and router, and a professional fighter understands the intricacies of balance and leverage, we must understand the small facets that provide the most significant results.
Learning the fundamentals of a programming language such as Java is an essential part of becoming a good programmer, but it is the small details that allow us to progress from good programmers to great craftsmen.
0 kommentar(er)
