This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I presume since Sun valid the interface methods themselves seperately I presume one needs to facilitate validating the record fields. Is this right? For example, the update method I have takes a String data array so I presume before a record can be updated, all fields within this array need to be validated? Would following be correct for the URLYbird assignement;
HotelName: can contain any US ASCII character
HotelCity: Can contain any US ASCII character
Max Occupancy: only contain integers
Smoking: Only characters N,Y,n,y accepted
Price: First character is valid currency symbol, rest is double
Date Available: use format given for date
CSR: valid 8 digit number
Is this correct? Any advice must appreciated.
You are rigth.
There 2 kinds of validation in this list: bussines and database.
The point of SCJD is 'how' and 'where' you'll deal with that !
There are a lot o option.....I'll tell you what was mine:
I've decided implement 3-tier designer where all this bussines validation was implemented in bussines tier.
Database validation was implement in persistence layer.
You can decide it based on how it yours design.
I chose to do the following validations.
magic cookie = correct file
each field length= as the database is shared with a legacy system and the format must be compatible
CSR number as this was a MUST
Locking is done in business layer and validated in data layer.
SCJP 6.0, SCJD (400/400), SCBCD for JEE 5, SCWCD 1.4 I do videos for development at
I am probably the only developer ever to have had an orange sized brain tumor in my brain while learning development!!
In the Data class, the validation I provided was just to verify if the arguments were not null, and if the objects in the String arrays were not null. I'd say that a validation more related to business should be put in the business layer. For instance, before booking a room, I verify if the customer ID is a valid 8-digit number. And since the only business behavior that deals with persistence we must implement is booking a room (via update() method), then I'd say that verifying if the user provided a valid 8-digit number is the only validation that you really have to do in the business layer (regarding persistence).
I followed a bit the same approach as the Great SCJD-master of Brasil. So my Data class takes care of validation against the database schema: I only checked for field length and if data can be converted to the allowed charset, so didn't apply already a check to see if smoking is one of [YyNn] (because it's not changed in application). And in my business service I validated the customer-id.
Thanks for your kind responses. Is this associated with checking the character set "UTF-8" when creating a new String from the String class and if encoding is not "UTF-8" throw UnsupportedEncodingException? I presume this line from the requirements "The character encoding is 8 bit US ASCII", therefore is not a business rule but a requirement? I presume when I'm writing out in the Data class, i check 2 things in the String data array, each elements length and whether a new String can be created for each element in the "UTF-8" format, if not UnsupportedEncodingException occurs? Thanks very much. I'm only talking about the data layer here.
Thanks for your replies. I tried the code below for reading and writing to file.
and used the below charset_name. The field string I'm using contains the euro symbol. I thought this may raise an exception when writing but it didn't. Also when I read in the euro symbol after writing, I get a ? symbol instead of the euro. Any ideas? Does the getBytes() create its own interpretation of the euro symbol.
Didn't do any tests with the euro symbol. But ISO 8859-1 does not declare the euro symbol. From the wiki-page:
Although ISO/IEC 8859-1 has enough characters for most French text, it is missing a few letters that are less common. It is also missing a single-glyph representation for the letter Ĳ, two Finnish letters used for transcription of some foreign names and in a few loanwords (Š and Ž), typographic quotation marks and dashes, and common symbols such as the euro sign (€) and dagger (†).