Get / Set methods are there to protect my class fields.
But since Java is working with reference my private fields are still getting exposed..
e.g.
private Date d;
Date getDate(){
return d;
}
void setDate(Date inD){
//Checks for inD
d = inD;
}
//Still the issue is
getDate().setHours(xyz);
What is the correct approach? Because i dont want to change my Date without using setDate.
Because i dont want to change my Date without using setDate.
Then you shouldn't return a reference to a mutable object in your get method. For example:
private Date d;
Date getDate() {
// Return a reference to an independent copy of the original data
return new Date(d.getTime());
}
void setDate(Date inD) {
// Checks for inD
d = inD;
}
A better approach (IMO) would be to use immutable types for your fields - the Joda Time API is a much cleaner date/time library and it has plenty of immutable types.
Now that was just an example of course - in other cases you might want to return an immutable view on a mutable object (which you would usually avoid mutating yourself) in order to avoid having to copy a lot of data on each get call.
There is a good approach for that which is called Defensive Copy,
Date getDate(){
return new Date(d.getTime());
}
you'll get a copy of it and original one will have no affect
Date is just an abomination since it is mutable. What you could do to make it safe, is to return a copy of the date. If that is modified, the original value is not changed.
Related
In the following example, x can be changed by class B even though it's a private member of class A. What's the reason for this?
import java.util.Date;
class A {
private Date x;
public A(){
super();
x = new Date();
}
public Date getDate(){
return x;
}
public void print(){
System.out.println(this.x);
}
}
class B {
public static void main(String[] args){
A a = new A();
a.print();
Date d = a.getDate();
d.setMonth(12);
System.out.println(d);
a.print();
}
}
The output is:
Initial date generated by A
Date changed by B
Date changed by B (why does it change a private member here?)
private prevents a variable from being accessed directly by another class. You cannot write d.x to read or write to x.
If the class chooses to return a reference to x via a public method, though, that's it's own choice to pierce the veil of privacy. Nothing stops A from allowing x to be read from a getter or modified from a setter.
In recent years the Java community has recognized the problem with this: namely, if you return a reference to a private mutable object, you open the door for your class's internal state to be mucked with without its knowledge. To protect against this, it has become good practice to make classes immutable whenever possible.
Indeed, Date is a perfect example of a poorly-designed mutable class. The java.time package introduced in Java 8 added a slew of immutable time and date classes to replace Date. You can now return a private Instant and not worry about callers being able to change it.
It's important to point out that immutability comes from how a class is defined. It's not a language-level feature like private. Confusingly, final can be used to make variables immutable, but applying it to a class does not make the class immutable (it makes it unextendable).
You're not changing the private property. Try this and see it fail:
A a = new A();
a.x = someOtherValue;
But the A class does allow you to read the property:
public Date getDate(){
return x;
}
And the Date class allows you to set its property:
d.setMonth(12);
No private member is being accessed outside of a class here. Date and A are two different classes.
This did not change x it is still pointing to the same object. What was changed is the object itself.
You are confusing reference with value.
The Date object referred to by x never changes and the field x is inaccessible from the sub class - ie the sub class can't assign a different Date object to x.
However, the getter allows you to access the object referred to by x, and (perhaps unexpectedly) Date objects are mutable - that is a Date's value can be changed. It's still the same Date object, but the instant in time it represents is different.
IMHO, the Date class is "broken"; it should be immutable.
The getDate() method is public. The getter method is public, that is you can now access the object and change its value. Date d and Date x are only reference to those objects not the actual objects.
sometime i have no choice to use mutable variable instead of immutable variables i know how many ways can create immutable vars but i wonder this way also correct its really convert mutable to immutable and i dont use concurrency or multithreading in my code just Curious?
public class Config implements FindIt {
....
private final class DateHolder{
private final Date dateContainDateObject;
DateHolder(String date) throws ParseException {
DateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.US);
dateContainDateObject = dateFormat.parse(date);
}
public Date getDate(){
return dateContainDateObject;
}
}
}
this is nested class and i use it like
private DateHolder holder;
and fill the holder variable in Config constructor class so holder variable are ThreadSafe ?
Date is a mutable object. Making it final means you can't change the reference to it, but you can still change what's at the reference (java.util.Date/Calendar nastiness strikes again, switch to the Java 8/Joda Time way if you can).
Don't expose any references to the Date member to the outside world. Instead make a defensive copy and pass that back instead. You might consider saving the time value as a final long instance member and only instantiating a Date when you need it.
can say is safe when you make class private and non-static, when you create form Config class you have only one DateHolder .
http://www.javapractices.com/topic/TopicAction.do?Id=29
why is static inner class singleton thread safe
http://www.javatpoint.com/how-to-create-immutable-class
I've created my own MyDate class. It basically wraps a Long value with some pretty toString() functions. I've implemented equals() and compareTo(). my program reads some data and instantiates object of classes that hold this MyDate class. Problem is that sometimes that data is bad so I created a public static final long NODATE = Long.MIN_VALUE; so that I could initiate a new instance that is empty (replace the null in the containing class so to avoid NullPointerExceptions). I've also implemented a constructor with no arguments that inits the Long value to NODATE.
My Problem:
I want to check if a MyDate is valued as NODATE. I can't compare to NODATE since it's Long and not MyDate. One way to do this is:
if someObject.myDate.equals(new MyDate()).
But it seems like a waste to create an object just to make the comparison? Another way is to implement MyDate.amINoDate() method.
Is there another way? I was thinking of creating an static instance of MyDate that is inited to NODATE and to compare to it. But how can I compare my non static objects to this static object?
class MyDate {
public static final MyDate NODATE = new MyDate(Long.MIN_VALUE);
// ...
}
// ...
if (someDate.equals(MyDate.NODATE)) // ...
Thanks maskacovnik.
You can also add a method to MyDate like:
public boolean isNodate() {
return internalLongDate == Long.MIN_VALUE;
}
Add a method to MyDate:
if (someDate.isNoDate()) {
...
}
Also: personally I would avoid the Long.MIN_VALUE and use null.
I have Date in this format 2009-09-17T00:00:00.000-35:00 . As per the business Rules for my Application , i have written 3 Methods which will accept this Date and returns the Date in MM/yyyy , yyyyMM and dd .
For example one method is shown below MM/yyyy
private String getMonthYear(String date) throws Exception {
DateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS", Locale.US);
String s1 = date;
String s2 = null;
Date d;
try {
d = sdf.parse(s1);
s2 = (new SimpleDateFormat("MM/yyyy")).format(d);
} catch (ParseException e) {
e.printStackTrace();
}
return s2;
}
Similarly i have other two methods which will return data in yyyyMM and dd formats ??
This works fine , but does not look good
My question is can we have only one utility which satisfies my requirement ??
My question is can we have only one utility which satisfies my requirement ??
I think you're going about this the wrong way to start with. Fundamentally the data is just a date. You can apply formats later, when you need to. I suggest you start using Joda Time and make your method return a LocalDate. That captures all the real information, and you can then have three separate DateTimeFormatter objects used to format the value whenever you want.
Wherever you can, represent data using a type which most naturally represents the real information. Get your data into that natural format as early as possible, and keep it in that format until you have to convert it into something else (such as a string).
You could define a single method and receive as a parameter the string with the expected date format, the three strings with the formats could be defined as constants.
Yes, you could group the three methods together, and use an additional argument (an enum, for example) to specify which kind of output format you want. But I would not do that. Your solution is cleaner. Why do you think it doesn't look good?
What I would do, however, is transforming the String to a Date once and for all, and using a Date everywhere rather than the String, and transforming the Date with one of your 3 methods (which would take a Date as argument rather than a String) when needed.
The Apache Commons Lang library already has utility methods to do this for you.
For example:
import org.apache.commons.lang.time.DateFormatUtils;
import org.apache.commons.lang.time.DateUtils;
///
// first, convert the string to a date object
Date parsedDate = DateUtils.parseDate("2012-05-25T16:10:30.000",
new String[] {"yyyy-MM-dd'T'HH:mm:ss.SSS"});
// now, format the date object to a string, using different formats
String formattedDate = DateFormatUtils.format(parsedDate, "MM/yyyy");
String formattedDate2 = DateFormatUtils.format(parsedDate, "yyyyMM");
Take a look at DateFormatUtils and DateUtils for more information.
You could just have a Date class which has the three methods. Like below:
public class MyDate {
private String date = null;
public MyDate(String date) {
this.date = date;
}
public String getMonthYear() {
return null;
}
public String getYearMonth() {
return null;
}
public String getDay() {
return null;
}
}
You can format the String into three different Strings in the constructor and just return those strings on method calls. That implementation would be good if you make numberous/repeated calls on the same date string. Or you could format the string in the method call, if you are doing it once but if you are doing it once you may want to make the class/methods static and get rid of the constructor.
Let's say I have a class Comment and I have a private field named commentDate which is a java.util.Date and with a getter named getCommentDate.
Why it's better to return a copy of that date ( return new Date(commentDate.getTime()) ) than simply returning that date...
How can a user change the object state of that Date since it's a getter, not a setter?
Since java.util.Date implements Cloneable you can easily clone the date, as:
public class DateTest {
private Date date;
public DateTest() {
}
public Date getDate() {
return (Date) date.clone();
}
public void setDate(Date date) {
this.date = (Date) date.clone();
}
}
First off, please, please, please avoid using getters and setters as much as possible. If you have both of them for the same field you are almost certainly doing something wrong. I don't care what the Java gurus are telling you. They don't know what they're talking about. This is not how OO works. OO is not a make-work project to turn field accesses into method calls. That doesn't actually encapsulate anything.
That said: if you return the date itself, then the calling code has a reference to your date object, and can use its full interface. Since dates are mutable objects, the interface includes things that can change the object state. Since the reference is to your date, your date's state will get changed. It doesn't matter how the calling code got the date (i.e. "with a getter").
How can a user change the object state
of that Date since it's a getter, not
a setter?
Easily:
Comment comment = new Comment();
comment.getCommentDate().setTime(0); // now it's January 1, 1970 00:00:00 GMT.
Follow Tapas Bose example, we can do the following using JAVA 8 to handle NULL cases:
public class DateTest {
private Date date;
public DateTest() {
}
public Date getDate() {
return Optional.ofNullable(date).map(Date::getTime).map(Date::new).orElse(null);
}
public void setDate(Date inputDate) {
this.date= Optional.ofNullable(inputDate).map(Date::getTime).map(Date::new).orElse(null);
}}
Reference: Is there a way to copy Date object into another date Object without using a reference? (Nicolas Henneaux's answer)
The user can't "replace" the instance provided by getCommentDate(). However, the user can invoke getCommentDate().setMonth(10) and thereby modifying the date. Thus, if this is a concern, I'd advise you to return a copy of the "original" instance.
Since java.util.Date is mutable, it could be changed via the getter like this:
getCommentDate().setYear(2011)
This will cause the commentDate on the comment to be changed to the year 2011. All other set methods on Date can be called as well off course, just an example.
In Java you are dealing with references. When you've a getter and returning your commentDate then you're in fact returning a reference to the object. That means that it is the same object like in your private field the caller can operate on due to reference returned by getter.
Note: Do not return mutable objects via getters eg. date (before Java 8). It can always be reset by a rogue programmer. Lets say you write a program where social security benefits of an employee is calculated based on the years of work.
public class Employee {
// instance fields
private String name;
private String nickName;
private double salary;
private Date hireDay;
// constructor
Employee(String name, String aNickName, double aSalary, int aYear,
int aMonth, int aDay) {
this.name = name;
nickName = aNickName;
salary = aSalary;
GregorianCalendar cal = new GregorianCalendar(aYear, aMonth - 1, aDay);
hireDay = cal.getTime();
}
//needs to be corrected or improved because date is a mutable object
public Date getHireDay() {
return hireDay;
}
A hacker/bad programmer can reset the date using a setter
Employee john = new Employee("John", "Grant", 50000, 1989, 10, 1);
Date d = john.getHireDay();
// Original hire date is Oct 1, 1989
System.out.println("Original hire date "+ d.getTime()));
long tenYearsInMilliseconds = 10 * 365 * 24 * 60 * 60 * 1000L;
long time = d.getTime();
// Hire date after hacker modifies the code
d.setTime(time - tenYearsInMilliseconds);
System.out.println("Hacked hire date "+john.getHireDay().getTime()));
}
Instead..return a clone of the date method for Java 7 or use LocalDate Class for Java 8
// for Java 7
public Date getHireDay() {
return (Date)hireDay.clone();
}
//for Java 8
public LocalDate getHireDay() {
return hireDay;
}