aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes criteriaFind() 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 "criteriaFind()" Watch "criteriaFind()" New topic
Author

criteriaFind()

Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi All,
Is it ok to implement criteriaFind() outside of the Data class? The only downside I see (and some may consider it a big deal) is that Data could conceivably be modified during the call, since you would only intermitantly hold the object lock on the Data object (ie you couldn't synchronize criteriaFind()) unless you synchronize on the Data object itself during the call.
Thanks for your opinions,
Michael Morris


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
If you can argue why it shouldn't be part of Data, it's fine I think. The fact that Data can be modified is unimportant -- the results of a criteriaFind are by definition stale by the time they reach the client anyway.
- Peter
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Peter,
Here is my thinking on the matter. I know that the provided source has been implemented and shown to work. Adding methods (or even adding code to unimplemented methods like lock and unlock) could introduce bugs into a known working class. It also breaks encapsulation as does inheritance in subtle ways. Therefore, all I have done to Data is fix the deprecated methods. Lock and unlock are handled in a LockManager, which Data has no knowledge of. Now as for criteriaFind, I created an interface named DataSearch which has criteriaFind as its only method. Doing it like this will make it easier somewhere down the road to extend the DataSearch interface for more robust searching without breaking any existing clients.
Let me know if you think I'm going astray here
Michael Morris
Adam Caldwell
Greenhorn

Joined: Mar 27, 2002
Posts: 17
The Data class is not a "known working class"... Take the null's bug in it that we've discussed here before as well as the deprecated methods... You need to modify the class anyhow.
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Adam,
My point is to only fix what is broken and provide the new functionality outside of Data and let it do what is has been shown to do ie retrieve and modify data. Is it not more intuitive to have a separate object responsible for locking and unlocking as well as one for performing searches? If you add or modify code (other than what is necessary for a bug fix) to a class do you not violate encapsulation? Finally, is not composition preferrable to inheritance?
I'm not saying that I'm 100% correct on this but is it a viable argument?
Thanks for your opinion,
Michael Morris
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Michael Morris:
Here is my thinking on the matter. I know that the provided source has been implemented and shown to work. Adding methods (or even adding code to unimplemented methods like lock and unlock) could introduce bugs into a known working class. [...]
Hmmm, I don't think this is a viable viewpoint. Think of the little classes, patches and kludges a software system would accumulate during its lifetime if it were maintained by these standards. Believe me, it's typically bad enough as it is
In an ideal world, Data would ship with a DataTest JUnit test harness or similar. The test harness would fully test Data's contract with the outside world, and as long as your modifications satisfied the test harness you could be 99.9% confident that you're fine. This is actually one of the key mechanisms behind Extreme Programming and its aggressive use of refactoring.
Your concerns are justified, and in my own experience JUnit has helped me spot bugs in interface implementations that had some subtle deviations from expected semantics. But that wasn't the SCJD assignment, so I digress...
Apart from the fact that Data is an unfinished product, as argued by Adam, I don't think this point of view is a viable one in software development.
- Peter
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: criteriaFind()