This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird's [Version 1.2.3] Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird Watch "URLyBird New topic
Author

URLyBird's [Version 1.2.3]

Payal Shah
Ranch Hand

Joined: Jul 10, 2006
Posts: 67
I am making the following assumptions about this method:

public long[] findByCriteria(String[] criteria)

I return all the records if :
1)if(criteria == null || criteria.length ==0)
2)if(cSize != DBSchema.getColumnLength())
// I know columnLength = 7 [name, location, size, smoking, rate, date,owner]

I have to do some validations for given criteria input array.
Are these assumptions gona work against me?
Bod Toki
Ranch Hand

Joined: Sep 01, 2006
Posts: 95
Hi..
The key here is to make sure there is no other requirement specified in the document that hinders your choices (or decisions).
Typically, if there are no restrictions, your design decision should be permitted if you explain why you have made the choice, and why you think it is an appropriate decision.

Looking directly at your choices here though, Here's how I'd categorize the choices.

(1a) return all if:
if (criteria == null).
-criteria can be looked at as constraint, and so if there are no constraints, return all records. I like this one.

(1b) return all if:
if (criteria.length == 0).
-no field of the criteria has been specified, and so pass all records. This is also not a bad one.

(2) return all if:
if (cSize != DBSchema.getColumnLength()).
-I am assuming by 'cSize' you mean 'criteria.length' because you did not specify what 'cSize' is. This could be looked at as: if some of the fields of the criteria have not been specified (or additional fields specified), return all records. In my opinion this may be a bad choice since you want your API users to be able to specify criteria in some fields but not be bothered by results from other fields. e.g. You want all 'smoking' records but are not bothered about 'location' and 'size'.

-But then again this depends on you and how you may have constructed other APIs and how you expect your APIs to be used.

Hope you understood me.
Take care.
Payal Shah
Ranch Hand

Joined: Jul 10, 2006
Posts: 67
for 2..
Let me put it other way
We have 7 columns in the database. so if someone passes criteria array with size = 9 ..then it is not good
So first I make sure that given Criteria array is size 7..only the size..
it can have its elements null {null, location, null, null, null, null, null}

So if the Criteria array size in not 7, then I return all records..
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
I chose to throw IllegalArgumentException in almost all of these cases, except when length is > 7, when only the first 7 elements of criteria are considered, while the rest are ignored. If criteria is null, or has a length < 7, then it means the caller made a mistake. As the interface states, if the caller wants all records, just send an all-null criteria.


SCJP 1.4 100%
SCJD 99.5%
Bod Toki
Ranch Hand

Joined: Sep 01, 2006
Posts: 95
for 2..
Let me put it other way
We have 7 columns in the database. so if someone passes criteria array with size = 9 ..then it is not good
So first I make sure that given Criteria array is size 7..only the size..
it can have its elements null {null, location, null, null, null, null, null}

So if the Criteria array size in not 7, then I return all records..


Payal...
I get your point now.
The basic choice here is whether you want to be strict about the parameters or not. If you intend to be strict with the input parameters for whatever reasons, you would be better off throwing some kind of exception. If the provided DB interface throws an exception that fits the situation, then throw that exception. Otherwise throw a RuntimeException like 'Alecsandru' is. If, on the other hand, you decide to be forgiving with the parameters, then you would probably just return all records (--which if not well explained in the documentation may appear confusing).

Sincerely, I think if you want to do this in a most elegant way you should design a layer above the database layer you have been given. In that case, you would have a DAO (data access object) that delegates to the DB interface you have been given, and you can pass in a Criteria object with the properties: [name, location, size, smoking, rate, date, owner] instead of the lower level String[] criteria. This way, users of your higher level API would find things clearer and easier. They would create a Criteria object, set the parameters they are concerned about, and then pass it to your DAO. Your DAO then converts the Criteria object to a 'String[] criteria' and delegates to your lower level DB interface. This way you can be very strict with the structure of your 'String[] criteria' and throw exceptions when it is not formated properly. However, it will still be a good idea if you allow 'criteria == null' to return all records in the database.

Hope you understood this, and hope it helps.
Bod Toki
Ranch Hand

Joined: Sep 01, 2006
Posts: 95
I doubt however that 'this kind of' design choice, however, would fail you on the exam. As long as you can explain and justify your choices.

When I did the exam, I made all sorts of design decisions that my experience writing software has taught me are not so nice, and I still passed the exam.

So you need not worry too much about 'grey area decisions'. Just make sure your application works, won't deadlock, and you are explaining (and justifying) your choices.

Payal Shah
Ranch Hand

Joined: Jul 10, 2006
Posts: 67
Thank you all for your help.
 
Consider Paul's rocket mass heater.
 
subject: URLyBird's [Version 1.2.3]