Find requirement seems inconsistent. Help

[Rag Srinivasan]

One of the "must" for the user interface is as follows "It 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." Please note the use of the words "exactly match"
But the data access class must support the following method.
/*
Returns an array of record numbers that match the specified criteria. Field n in the database file is described by criteria[n]. A null value in criteria[n] matches any field value. A non-null value in criteria[n] matches any field value that begins with criteria[n]. (For example, "Fred" matches "Fred" or "Freddy".)
*/
public int [] find(String [] criteria) throws RecordNotFoundException;
How does one reconcile what I perceive as inconsistent ? If a name "Fred" is specified then only a record that contains "Fred" should be returned according to the UI, but the Data Access Class will return all records that satisfy "Fred*" (say "Fred" andd "Freddy" assuming those two records exist) To have to do more processing in an intermediate layer that takes in both the records and throw out everything (in this case, record containing "Freddy") except "Fred" (which is then passed to the UI) seems to be wasteful.
Can some enlighten :-)
thanks in advance.
-- Rag

[Jim Yingst]

Reading carefully, it the requirement is that you be able to find records where the name and/or location fields are an exact match - but it doesn't say that you must find only those records. In the example you cite, the user can find the exact match of "Fred" - it just happens to be returned along with the inexact match of "Freddy". I don't see a problem with this; the requirements are vague enough IMO that this should be acceptable. It's not our fault they weren't more clear - just document your reasoning. Another option though is to continue to implement find() exactly as written for Data.java, but then add some additional filtering functionality in another class which calls Data. (Most designs have some sort of facade class involved; this is a good place for it.) Just call find() and loop through the results to find any row(s) which exactly match the specified criteria.
Yet another possibility is to add additional methods to Data which provide the functionality you want. I was pretty tempted to put in various minor enhancements to find() (things like ignoring case, or using indexOf() rather than startsWith() if the user didn't need the substring to be at the beginning of the search field) but decided not to because (a) we're not asked to do so, and (b) the find() method is a pretty crappy API as far as extensibility is concerned anyway; any real-world application would be better off just replacing it entirely rather than trying to build on it, IMO. So despite temtation, I just stick with what they explicity ask for here. (Which is what everyone else will probably tell you to do anyway.)

[S. Ganapathy]

Hi Jim,
I too thought like you regarding find method. I initially tried using indexOf(), but after going through the instructions carefully, I could not able to take risk of using indexOf() and changed to startsWith(). Ofcourse, am too using case insensitive approach to find the records.
BTW are you using FileChannel to read and write data from/to db.db? Am thinking to implement the same, as a last moment thought.
Regards,
Ganapathy.

[Jim Yingst]

Oh, you're making the search case insensitive? I had decided not to, but I suppose it could be justified the same way I justify returning both "Fred" and "Freddy".. My feeling is case insensitivity would be preferable in the real world (or better yet, a checkbox to choose whether to use it or not), but I'm not sure it's such a good idea here. I may yet flip-flop some more before I turn in my assignment.
FileChannel - yeah, that's what I use. Pretty simple really - it's just unfamiliar to most of us initially.

[Rag Srinivasan]

Originally posted by Jim Yingst:
Oh, you're making the search case insensitive? I had decided not to, but I suppose it could be justified the same way I justify returning both "Fred" and "Freddy".. My feeling is case insensitivity would be preferable in the real world (or better yet, a checkbox to choose whether to use it or not), but I'm not sure it's such a good idea here. I may yet flip-flop some more before I turn in my assignment.
FileChannel - yeah, that's what I use. Pretty simple really - it's just unfamiliar to most of us initially.

I came to the same conclusion as you did regarding a facade to filter out the unwanted results that find may generate. And you are correct about the requirements being both vague in parts and totally over specified in others !! IMO details like lock() and unlock() should not be in the interface at all. I do not plan on exposing them to clients anyway. As you had suggested I plan on using a facade that implements CRUD and Find and that uses Data.java. The facade calls lock and unlock before making any other calls.
Thank you
-- Rag

[Dieter Verheyde]

Hi Rag,
I've got exactly the same assignment and faced the same problem.
I decided to implement the find as defined, meaning with startsWith but ignoring the case.
In my gui search is possible on name, location and specialitie. Added specialitie because of the general specs saying "..they take requests from home owners for a type of service...".
Didn't filter, maybe better for the specs but just seems stupid, then you can as well read in
the entire db and create dropdowns.

[Perry Board]

In the example you cite, the user can find the exact match of "Fred" - it just happens to be returned along with the inexact match of "Freddy". I don't see a problem with this; the requirements are vague enough IMO that this should be acceptable.

I disagree with this. The requirements may be vague, but "exact-match" seems to me to be mutually exclusive to "nonexact-match." If your GUI shows "Freddy" which is NOT an exact match, then it is failing in that requirement. I think the concept of additional filtering is necessary in order to meet both requirements of the interface (begins-with) and GUI specification (exact).

[Jim Yingst]

[Dieter]: I decided to implement the find as defined, meaning with startsWith but ignoring the case.
How do the instructions imply that you should ignore case? I agree it seems reasonable for a real-world application, but I just don't see it in the actual requirements.
[Perry]: The requirements may be vague, but "exact-match" seems to me to be mutually exclusive to "nonexact-match."
I suppose you're right. It's not difficult to add a filter to take care of this, and it's only a slight increase in complexity - make the filter nice and modular, and clearly identify what it does and why. I still think that this is not necessary to fulfil the literal requirements as written, but it's probably a good idea to fulfil the apparent intent fo the requirements as well if possible - despite the inconsistencies which indicate that the persons developing the requirements didn't really know what they wanted. (Or in this case, Sun wanted to intentionally simulate clueless customers for our benefit.) :roll: Ah, well...
[ June 26, 2003: Message edited by: Jim Yingst ]

[Dieter Verheyde]

Thanks for the remarks.
My idea was to consider the usability of the application as well, having to type in exactly a name like "Buonarotti & Company"(ex from the db).I'd never want such an app...
But maybe that's my biggest problem with the entire app, do you go for a handy tool for the users or do you stick with the exact specified requirements.
Guess everything depends on how thing are evaluated...

[Jim Yingst]

But maybe that's my biggest problem with the entire app, do you go for a handy tool for the users or do you stick with the exact specified requirements.
Yeah, I have the same problem. In the case of the find() method, I considered various possible "future enhancements" and how they might be integrated into my design, and ultimately decided that for a real application I would really want to deprecate find(String[]) ASAP and replace it with something like

public interface DB {
    ...
    public List find(SearchCriteria crit);
    ...
}
public interface SearchCriteria {
    public boolean accept(String[] values);
}

This would allow much more flexibility in specifying search criteria. (E.g. ignore case, use indexOf() rather than startsWith(), use a regex, interpret as Date or int rather than String, etc.) And returning a List (of String[]) would allow us to return the actual record values, rather than just returning row numbers and forcing the client to read each row number separately (creating unnecessary network traffic). Furthermore in a high-volume system the List could be implemented sort of like a ResultSet, so that it has the option of not sending all data across the network until a specific row is requested. E.g. if there are 5000 rows in the List, you probably just need 20 or so to display at a time - a custom List implementation could manage this sort fo thing for optimum efficiency. O.K. that's way out of scope for this assignment - but my point is the interface should really be made more flexible now, IMO. Which leads me to: the find() method, as specified, sucks, and I'm not really interested in doing anything with it beyond the bare minimum specified. If the customer wants enhancements later, they should make (or allow me to make) a new method. Don't kludge enhancements onto the existing find().
On reflection, there's probably a reason why my previous bosses have been careful about having me talk to customers.

[Jacques Bosch]

[Perry]: The requirements may be vague, but "exact-match" seems to me to be mutually exclusive to "nonexact-match."
I suppose you're right. It's not difficult to add a filter to take care of this, and it's only a slight increase in complexity - make the filter nice and modular, and clearly identify what it does and why.

OK, here's a nice thought for you.
If "exact match" is to be taken literally, then entering "Smallville" in the location field won't be valid for any records. Because all the fields have been padded with spaces to the length of the field and is part of the field value, strictly speaking.

[Stephen Galbraith]

If "exact match" is to be taken literally, then entering "Smallville" in the location field won't be valid for any records. Because all the fields have been padded with spaces to the length of the field and is part of the field value, strictly speaking.

Agreed
like a lot in this assignment, I'm just taking a document it and move on attitude (I mean, it tells us to in the destructions (sorry instructions))

Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.

[Jacques Bosch]

Nice, Stephen. I like that.