dcsimg
Login | Register   
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Tip of the Day
Language: Java
Expertise: Beginner
May 23, 2018

WEBINAR:

On-Demand

Application Security Testing: An Integral Part of DevOps


Calling Date.setTime()

account.changePassword(oldPassword, newPassword);
Date lastModified = getLastModified();
lastModified.setTime(System.currentTimeMillis());

The above code updates the last modified date of the password and wants to avoid creating a new Object, but uses instead the setTime method to modify the existing Date instance. There is nothing wrong with that, however, it is not recommended to follow this practice because the Date objects are usually passed carelessly. The same Date instance could be passed to numerous objects, that don't make a copy in their setters.

Dates are often like primitives. If you modify a Date instance, other objects that use this instance might behave unexpectedly. However, the general everyday Java practice is to copy Date references and not clone the object in the setters, so every programmer should treat Date as immutable and should not modify existing instances, this should be done only for performance reasons in special situations.

account.changepaasword(oldPassword, newPassword);
account.setLastModified(new Date());

Using one class or interface that contains all kinds of constants used during the application may not be the best solution, because these constants are unrelated with each other. The only thing that they have in common is the interface or the class and the reference to this class will contaminate many other unrelated components of the application. What if you want to share some classes between a server and a remote client? Or later extract a component and use it in another application? This class has created a dependency between unrelated components and this limits both reuse and loose coupling. You should never place constants across components boundaries, this is an exception only if the component is a library, and an explicit dependency is wanted.

Octavia Anghel
 
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
×
We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date