JAVA CALENDAR SETDATE CODE
This example retains the readability of the traditional individual "set" methods approach with the added safety of having the object populated fully immediately at instantiation.įor developers who want to provide fewer individual "set" methods, another opportunity with Calendar.Builder is to use the setDate(int, int, int) and setTimeOfDay(int, int, int) methods as demonstrated in the next code listing.Ĭalendar.Builder Setting Date and Time as Two Calls /** In the above code listing, the Calendar instance is created AND populated in one statement, removing the need to risk an object being in an inconsistent state across multiple statements.
"Calendar via Calendar.Builder 'set' Fields: " setTimeZone(TimeZone.getTimeZone(timeZoneId)) Public static void demoCalendarWithCalendarBuilderSetFields() * Calendar using the set methods to set each field individually based on * Demonstrate using JDK 8's Calendar.Builder to instantiate an instance of The single-set approach is a little unwieldy because it takes six integers that can be easily mixed up in order passed because there is no obvious way to differentiate which integer is which other than the implicit order.Ĭalendar.Builder leverages on the advertised benefits of the Builder as described by Bloch: removes the existence of "inconsistent states partway through construction." This is demonstrated in the next code listing.Ĭalendar.Builder Allows Single-Statement Instantiation with Readable Settings /**
The single "set" method has fewer states of an "unfinished" object than the multiple-set approach, but the multiple-set approach is more readable because the name of the value being set is clear based on the first parameter to each "set" method. One extreme is to set each individual field separately while the other is to set all the significant fields with a single "set" method. The two "traditional" approaches shown above show different ways to populate the Calendar instance. As I have previously written, static imports seem to be increasingly popular with Java developers, especially in light of the trend toward fluent interfaces. The constants such as ENGLISH, YEAR, and SECOND are actually statically imported from classes such as Locale and Calendar. SIDE NOTE: In both of the examples above, I used another increasingly popular feature of modern Java: the static import. Out.println("Calendar via set methods: " + stringif圜alendar(calendar)) Public static void demoCalendarWithIndividualSets() * individual "set" calls for each pair of field names and values. Populating Calendar with Multiple Individual 'set' Methods /** Out.println("Calendar via Constructor: " + stringif圜alendar(calendar)) Public static void demoCalendarWithSingleSet()Ĭalendar.getInstance(TimeZone.getTimeZone(timeZoneId),Ĭt(2013, APRIL, 6, 15, 45, 22) * Demonstrate pre-JDK 8 method of instantiating Calendar instance using Populating Calendar with Single 'set' Method /** These two typical approaches for populating a Calendar instance are demonstrated in the next two code listings. Today, a Java developer typically populates an instance of the Calendar class by either calling one of the "set" methods that accepts a lengthy list of content for the instance or by calling individual "set" methods on the instance one after another. In this post, I briefly introduce Calendar.Builder coming to JDK 8. There have been several builders added to the JDK including the addition of Locale.Builder in J2SE 1.7. Josh Bloch brought the pattern to the forefront of Java developer community mindset with coverage of the pattern in Item #2 of the second edition of his highly influential Effective Java. Groovy, which appears to be the most popular alternative language (to Java) on the JVM, is well-known for its heavy use of the Builder in both the core libraries and in Groovy-supported libraries and frameworks.
One of the defining characteristics of the brave new world of Java is the increasing prevalence of the builder pattern in the Java space.
0 kommentar(er)
