I'm also worried about the definition of "reasonable" number of classes.
I recently finished coding all the required functionality for the certification. I've currently got 37 classes and interfaces. I tend to use lots of classes; I think more simple classes are easier to understand than larger, more complicated classes. I'm now considering adding around 5 more classes!
I know the certification says
you should make the design easy for a junior programmer to understand, but it doesn't say that means only using a few classes. I think my design is pretty good - I've used several design
patterns to separate various pieces of reusable logic. For instance, I have separate classes (and interfaces) for the reading/writing of the database file and searching the database file. This makes it really easy to change your search algorithm, even at runtime. I've gone the extra step in several places that gives me a lot of classes. I think this has clarified the design and responsibilities of the various parts verses complicating them.
I also made some middleware between the server and the client that accounts for some of the additional classes. I'm glad I did make the middleware; looking back it has come in really handy. I put in the padding of database fields here, I lock the entire database before a close, I ensure that the client never (unless it crashes) leaves a record locked, I only give the client a limited number of operations, etc.
I just can't make myself take away good design and flexibility simply to get the number of classes down to some artificial magic number.
Comments and disagreements are welcome.
,Marcus