This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
In my assignment, i'm provided some smarts to the search functionality..for instance my search code is case in-sensitive
I agree with Jeroen - you're taking a risk here, but if you document you thoughts on the subject in the choices.txt you probably would get away with this.
and will match a value if it starts with the value entered by the user.
I think this is an auto-fail. My spec says the server MUST perform a search where a record is returned if a field String starts with the associated criteria String (what you are proposing), but my client-side spec states that only an EXACT match for the fields MUST be returned.
Many posts I've read on the Ranch believe that Sun have deliberately given you different search specs for client and server in order to see if you have read and understood the requirements.
I know it could be argued that you are helping out your users by providing better functionality, but I don't think it's worth deviating from the given specs (and if in doubt I usually think about what I do in the real world - here in a real project I wouldn't add functionality to a search algorithm/mechanism if the client had signed-off, but I probably would mention this as an possible addition)
Daniel [ August 16, 2006: Message edited by: Daniel Bryant ]
Originally posted by Jeroen T Wenting: What I did was implement both and expose only the exact match through the client (though it could be rapidly changed to use the other match by changing a single flag in a single method).
I took the same approach. Doing this means that you satisfy both the requirements of the data class and the requirements of the client.
I used a couple of radio buttons on the GUI to select between starts with and exact matching. That way, it allows a picky examiner to carry out an exact match if they want to. The interface specified that the Data class should do a "starts with" search, so it was easy to filter those that didn't "exactly" match.
However, I left everything case sensitive. That's because the Data class had to implement the supplied interface and making it case-insensitive would mean that potentially the search method would return too many records. While you can filter these in YOUR application, someone else using your Data class may not expect that behaviour. In other words, it could be argued that you haven't implemented the interface correctly - and I didn't want to take that risk!
Joined: Aug 15, 2006
Excellent replies. I completely agree with the arguments raised. Thanks all.