Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Match case and look for available only

 
Seid Myadiyev
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am considering to give operators an option with regards to 2 points which specs does not address in detail:
1. [Match case] -> Indicates if comparison of record against criteria is case-sensitive.
2. [Only available] -> Indicates if only available (not booked) rooms must be returned.
Both of these are boolean variables. My questions is: Considering the limitations imposed by the specs, how do I communicate this information to the server without making my application look/seem complicated?
My understanding is that I need a Criteria class which will encapsulate needed search information in its fields, for which I must provide at least getter methods. My Criteria class extends Record in order to avail of the same functionality that Record has and to be of the Record type. Example:
Criteria criteria = new Criteria(fields, matchCase, availableOnly);
... = find(criteria);
// where method "find" is:
public List find(Record criteria) throws Exception;
For this particular assignment, does this approach seem like a good design to you? Please advise!
Thank you in advance!
Seid
 
Seid Myadiyev
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am sorry, left out NX in subject line.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Seid,
Considering the limitations imposed by the specs, how do I communicate [additional] information to the server without making my application look/seem complicated?

The method signature for the find() method in the Data class is well defined - I would not change it. You may also feel (as I do) that you should make this method available on the server (see this thread for more on that). But there is nothing to say that you cannot add other methods to the Data class and/or to your server if you want to (as long as you don't add it to the interface). Likewise there is nothing to say that your client has to call the find() method that is mandated in the Data class.
Does that give you a hint?
For this particular assignment, does this approach seem like a good design to you?

I don't believe it is necessary for the SCJD, but it is something that I would like to see in a commercial design.
I am sorry, left out NX in subject line.

No problem.
But if you ever want to go back and change your original post (including changing the subject line) you can click on the icon that appears above each individual post. That will let you go and edit your post.
Regards, Andrew
 
Seid Myadiyev
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew, thank you very much for your response!
I am writing again just to clarify.

Does that give you a hint?

Yes, I get the hint. I have a business method which client invokes only once (per search request) for the matching collection to be returned from server, and it looks nice (and works well). I am only concerned about creating an additional class; in this case - Criteria (which will be an addition to already existing class Record).
So I wanted to know your opinion about the idea of creating this new class (Criteria).
For example, when you said: "I don't believe it is necessary for the SCJD ...", were you referring to adding a new class (Criteria) to the design? If yes, then does it mean that in your view it is not necessary to pass this (additional) information at all, (i.e no need at all for such functionality: match case and find available only, for SCJD). Or that it is not necessary to do it by means of new Criteria class and do it some other way? For example, just pass them as 2 plain booleans.
Thank you for your reply in advance.
Seid
[ December 17, 2003: Message edited by: Seid Myadiyev ]
[ December 17, 2003: Message edited by: Seid Myadiyev ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Seid,
I think you are going beyond the requirements in allowing the user to select a case insensitive search and allowing the user to show or hide booked records. I think these are both nice features, and in a real project I would like to see either the specification clarified or those features added, but for this assignment I don't believe either functionality is required.
If you do decide to implement that functionality, then creating your Criteria class is (IMHO) a good way of doing it.
For case sensitivity, do you have a requirement that the GUI display records where the "fields exactly match values specified by the user"? Personally I would use that as endorsment of doing a case sensitive search.
For the showing or hiding booked records - I think this is a personal thing. The argument for hiding the booked records is that it reduces cluter. The argument for showing booked records is that the operator can see what has been booked in the past - therefore what might be available (instead of saying "sorry we have no listing of hotels/contractors in your area", they can say "sorry all our hotels/contractors in your area are booked on that date - do you want me to check the previous/next day?") or to confirm that a record has been booked ("yes sir, I can see that the contractor/hotel is booked on that date with your reference number"). So you could go either way, and just put your reasoning in your design decisions document.
With the hiding / showing booked records, if you did have such functionality, I would be tempted to only put it in the GUI - don't have anything server side. So the server sends all records (booked or unbooked) and then the GUI filters them according to user options. We are not talking about huge amounts of network traffic for this, but it means a faster response if the user changes the option (and it does not require extra network traffic / database searches each time they change their mind). The same could also be done with case sensitivity - but then you would have to make a decision to always do case insensitive searches on the server: not so sure about that.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic