Object Control Creation – From Constructor?

[Declan Dee]

Hi Gents,

This is something that I am stuck on.

I am creating a constructor that can take in variables of the following type:

public Date(int day, int month, int year) {
this.day = day;
this.month = month;
this.year = year;

I need to change so that if an object is created of type date and this date is before a certain date e.g. 12/01/1977 that a message is generated.

So basically what I am saying is that I want to use the constructor to control what object can be created.

The second thing that I am looking for is to make sure that a date entered must be between two specific dates and not outside This is my pathetic attempt so far:

    
public boolean checkDate(Datum datum) {
        Calendar cal1 = Calendar.getInstance();
        int year = 1584;
        int month = 00; //January
        int day = 00; //1st of January
        cal1.set(year,month,day);

        Calendar cal2 = Calendar.getInstance();
        int year2 = 4099;
        int month2 = 11; //December
        int day2 = 31;
        cal2.set(year2,month2,day2);

        Calendar cal3 = Calendar.getInstance();
        cal3.set(datum.jaar, datum.maand, datum.dag);

        if( cal3.before(cal1) )
        return true;
        else
            return false;

        if (cal3.after(cal2)) //An error is here!
            return false;
        else
            return true;


    }

For the life of me I have absolutely no idea on how I can achieve these, or where even to start.

Can someone be so kind as to shed some light on these please?

Declan

[Sean Clark]

Hey,

I think you have a small error here:

        if( cal3.before(cal1) )   
            return true;   
        else  
            return false;   
  
        if (cal3.after(cal2)) //An error is here!   
            return false;   
        else  
            return true;   

This code will always return true or false from the first check so it will never get to your error line.

I think you want something more like (I prefer using curly brackets too):

        // if date is before start date or after end date then return false as date is invalid.
        if(cal3.before(cal1)  || cal3.after(cal2)) {
                return false
        }
        // otherwise it is allowed - return true
        return true; 

Hope that helps.

[Declan Dee]

It does indeed Sean - Thank You!

Now I have to find a way of taking this (now working method) and run it against objects in a Treeset

[Dave Lorde]

Declan Dee wrote:I need to change so that if an object is created of type date and this date is before a certain date e.g. 12/01/1977 that a message is generated.

Something like this?

static Calendar threshold = new GregorianCalendar(1977, 1, 12);

public Date(int day, int month, int year) {
        this.day = day;
        this.month = month;
        this.year = year;
        Calendar cal = new GregorianCalendar(year, month, day);
        if (cal.before(threshold)) {
            displayMessage(String.format(
                 "Date %1$d/%2$d/%3$d is earlier than 12/1/1977", day, month, year));
        }
}

So basically what I am saying is that I want to use the constructor to control what object can be created.

That's not what you said - you said you wanted a message displayed if the requested date was before a certain threshold date. If you want to stop construction if the requested date is before the threshold, you should throw an exception:

static Calendar threshold = new GregorianCalendar(1977, 1, 12);

public Date(int day, int month, int year) {
        Calendar cal = new GregorianCalendar(year, month, day);
         if (cal.before(threshold)) {
            throw new IllegalArgumentException(
               String.format(
                  "Date %1$d/%2$d/%3$d is earlier than 12/1/1977", day, month, year));
        }
        this.day = day;
        this.month = month;
        this.year = year;
}

The second thing that I am looking for is to make sure that a date entered must be between two specific dates and not outside

For this, you just need to compare with the high and low dates (using calendars):

Calendar lowDate = ...
Calendar highDate = ...
Calendar thisDate = ...
...
if (thisDate.before(lowDate) || thisDate.after(highDate)) {
   throw new IllegalArgumentException("Date out of range");
}
...

But if you're going to use the Calendar class, why not use the SDK Date class (or better still, the JodaTime classes) ? Why reinvent the wheel?

[Campbell Ritchie]

Why are you trying to control creation from inside the constructor? Is it because you have a class invariant that the values must be in a particular range? If so, I think the IllegalArgumentException technique looks better to me.

[Declan Dee]

Campbell Ritchie wrote:Why are you trying to control creation from inside the constructor? Is it because you have a class invariant that the values must be in a particular range? If so, I think the IllegalArgumentException technique looks better to me.

Yes indeed. First my thanks to Dave for his help. Thanks Dave, Greatly appreciated.

so, yes, I have to make sure that no object (in this case a employee) can be created with a date less than the 1st of January 1977. If I create an employee with a start date that is less than that, there has to be an error.

You see the company was set up on that date so it was impossible that a start date for an employee could have been before that. Hence the control.

Thank you very much indeed

[Jim Hoglund]

How about making your constructor private and using MyDateClass.getInstance(day, month, year)
to police the dates. It can return null if the date is out of range.

Jim ... ...

[Dave Lorde]

Jim Hoglund wrote:How about making your constructor private and using MyDateClass.getInstance(day, month, year)
to police the dates. It can return null if the date is out of range.

It's certainly possible, but AIUI, throwing an exception is the cannonical way to handle constructor failure, because it provides error information and flexible, typed error handling. This is the sort of thing exceptions are intended for. Returning a null from a getInstance method means having to handle the error in-line in the code without any useful information and compromises the creation idiom for no good reason - and with some potential for confusion (e.g. is it a factory class, or some kind of singleton?). YMMV.

[Jim Hoglund]

Okay, but does it not depend if an out-of-range date is truly an
error, or just something you want to screen out? Throwing an
exception is a good idea if your work flow supports immediate
correction, through a GIU, for example.

Jim ... ...

[Paul Clapham]

Let's suppose you implement this business rule ("The hire date can't be before the date the company was formed") by having this Date object throw an exception. That's certainly valid Java code, and it might be the right thing to do in some contexts.

But now the scope of the project creeps on and we have other business rules. Like "The hire date for nursing personnel can't be before the date the company acquired the nursing home". Now your Date object can't validate that business rule because it doesn't know whether it's being used for a "nursing personnel" or not. That tells you that you went down the wrong road with the initial design, and now you have to go back and redesign a separate validation facility for your application.

So yes, you can certainly implement your constructor as you originally asked. From a technical point of view, that is. But there are a lot of situations where you shouldn't implement it that way, instead having something else validate the data before calling the constructor.

[Dave Lorde]

Jim Hoglund wrote:Okay, but does it not depend if an out-of-range date is truly an
error, or just something you want to screen out?

Yes, of course. Putting that validation in the constructor says a Date object cannot take those values - they are not valid Date values. Whether this makes sense in the design is something only the designer can adequately decide. I agree that in this particular case, it seems unlikely that as generic an object as a Date should be restricted to a specific range like that, and having to reject what appear to be valid date values would make me look again at my design. If it was just a question of filtering out certain dates from the range of all dates (for example, dates in the 21st century, or birthdates of people over pension age, etc), then a filter/comparator would do the job. I suppose a subclass could be used in some situations, although I can't think of an appropriate use offhand. On the other hand, for a limited application that only ever deals with a certain range of dates, the constructor exception might be a good compromise - although it wouldn't be a useful library class... it all depends.

[Dave Lorde]

Paul Clapham wrote:Let's suppose you implement this business rule ("The hire date can't be before the date the company was formed") by having this Date object throw an exception. That's certainly valid Java code, and it might be the right thing to do in some contexts.

Yes, doing it that way suggests the class should be called HireDate and be a subtype of Date - which doesn't look sensible For a date constructor you'd generally be throwing an exception if the parameters can't construct a valid date (e.g. 0 < month value < 13) rather than restricting the date itself to an arbitrary range. Business rules are not generally involved in type specifications that way.

So yes, you can certainly implement your constructor as you originally asked. From a technical point of view, that is. But there are a lot of situations where you shouldn't implement it that way, instead having something else validate the data before calling the constructor.

Agreed.