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.


advertisement
 

Tip: Calling Date.setTime()

See why it is inadvisable to use the setTime method to modify an existing Date instance.


advertisement

WEBINAR:

On-Demand

Application Security Testing: An Integral Part of DevOps


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.

 

Visit the DevX Tip Bank

 





   
Octavia Andreea Anghel is a senior PHP developer currently working as a primary trainer for programming teams that participate at national and international software-development contests. She consults on developing educational projects at a national level. She is a coauthor of the book "XML Technologies--XML in Java" (Albastra, ISBN 978-973-650-210-1), for which she wrote the XML portions. In addition to PHP and XML, she's interested in software architecture, web services, UML, and high-performance unit tests.
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