• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

criteriaFind()

 
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic