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

CriteriaParser

 
Marcos Motta
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I created a class named CriteriaParser, responsible for parsing the database search criteria and matching records against it.
CriteriaParser is designed to help the implementation of Data.criteriaFind. It made the criteriaFind implementation smaller and clear. In case the criteria syntax evolves, the additional complexity will be confined in the CriteriaParser class, leaving the method criteriaFind unchanged.
A made CriteriaParses public, but I feel that it is not right because it does not provide anything useful for the user.
I am inclined to declare it "package protected" (with no visibility attribute. Is it the name?), but if I do so, classes derived from Data, for instance, will not be able to use CriteriaParser (Am I right).
But, if I leave it public, javadoc pages will be created . The user should not be aware of this class
I would like to have your comments, please.
thanks
[ July 18, 2003: Message edited by: Marcos Motta ]
 
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 Marcos
I created a class named CriteriaParser, responsible for parsing the database search criteria and matching records against it.

I did something very similar with mine.
I am inclined to declare it "package protected" (with no visibility attribute. Is it the name?), but if I do so, classes derived from Data, for instance, will not be able to use CriteriaParser (Am I right).

I think most people just refer to that as "package" or "package level" access. They do not use "package protected" together, as it might cause confusion with the "protected" access level.
If you do make this package level, then any class in the same package will be able to access it.
So a class that extends Data class, that is also in the suncertify.db package will still be able to access it because it is in the same package.
But, if I leave it public, javadoc pages will be created . The user should not be aware of this class

In a real life application, you might be right. But for this application, I don't think we need to worry about that. Look at the sample code provided by Sun: the FieldInfo and DataInfo classes are all public as are their methods.
You may have other reasons for changing the access level from public to something more restrictive, but I would not recommend changing access levels just because of the javadoc.
Regards, Andrew
 
Marcos Motta
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic