This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Implementing search method in business layer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Implementing search method in business layer" Watch "Implementing search method in business layer" New topic
Author

Implementing search method in business layer

Paweł Baczyński
Bartender

Joined: Apr 18, 2013
Posts: 915
    
  14

Hello. My assignment says:

[The GUI] must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.

So I am wondering which kind of interface to implement.

1.
2.
3.
4.
5.

1 and 2 require a client to send a Map pairing a key (field name) to its value. The second version lacks getAllRooms as it is somewhat redundant (passing an empty Set would mean the same as calling this method).
The main advantage of this approach is that it allows adding new searching patterns easily.
A drawback: its more complicated to implement.

3, 4, and 5 try to do this differently. The requirements ask for search by name/location so it is all the interfaces do. No more. There are some variants but the main idea is the same.
An advantage: easy to implement
A drawback: adding new search criterias would require to add new methods

What is the best? Well, I don't ask you to tell me what to choose.
I just want to know if implementing 3, 4 or 5 could cause me to lose some points (as being hard to modify).


Formely Pawel Pawlowicz
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5216
    
  12

I didn't implement a seperate getAllRooms method.

I don't want to sound harsh, but I don't like any of your interfaces The main reason why I don't like them. I don't like the map, because it lacks compile time safety (your keys could be everything, even case sensitive). I don't like the methods where you have name and location as seperate parameters, because that would require an interface (contract) change if for a new version you have to add an optional date range. Another (minor) reason: you use arrays instead of List.

There is an alternative that gives you the advantage of a map (just 1 parameter, always the same, no matter how many criteria you have) with the advantage of the seperate parameters (compile time safety). I'm curious if you can think of it. And if you can, you'll know how my interface was defined


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 737
I did something similar :


The input criteria is a string like this: [room name, room location, ....]
The searching algorithm is like like :
1. search for room name. if room name is an empty string like this "", all records will be matched.
2. search for room location. If room location is an empty string, all records will be matched.
3. If a match is found for room name and room location is empty , then return all rooms with that name.
4. The same thing for room location.
5. Of course, if name and / or location won't match, it returns nothing.


Paweł Baczyński
Bartender

Joined: Apr 18, 2013
Posts: 915
    
  14

Roel De Nijs wrote:I don't want to sound harsh, but I don't like any of your interfaces

Don't worry. I don't like any of them either. If I felt comfortable with them I wouldn't ask.

Roel De Nijs wrote:Another (minor) reason: you use arrays instead of List.

What's wrong with arrays?

Roel De Nijs wrote:There is an alternative that gives you the advantage of a map (just 1 parameter, always the same, no matter how many criteria you have) with the advantage of the seperate parameters (compile time safety). I'm curious if you can think of it. And if you can, you'll know how my interface was defined

Hmmm. Are you thinking about enums? Something like this?


I think you didn't mean something like this. This would require that a client knows how the service is implemented. Right?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5216
    
  12

Nothing is really wrong with arrays, but a List is easier to work with. In your search method how are you populating your array? Because you have no idea about how many records will be returned. With a List you just create one and add as many elements as you need, without any problem.

Certainly not with enums, that's even worse! What do you think about a specific RoomCriteria class which you can pass to your search method? For now it has 2 properties (name and location). If next week you have to add a date range to your search, you can simply add 2 extra properties to your object (beginDate and endDate), no changes to method signature and update your code on server/client appropriately.
Paweł Baczyński
Bartender

Joined: Apr 18, 2013
Posts: 915
    
  14

Roel De Nijs wrote:What do you think about a specific RoomCriteria class which you can pass to your search method? For now it has 2 properties (name and location). If next week you have to add a date range to your search, you can simply add 2 extra properties to your object (beginDate and endDate), no changes to method signature and update your code on server/client appropriately.

So simple! So obvious! Why did I miss that? ;)
 
jQuery in Action, 2nd edition
 
subject: Implementing search method in business layer