Consistency is king when it comes to organizing code. I work on various engine middleware and have ~1500 classes to organize. It's long past where I can memorize every single class name.
As far as code architecture is concerned the MVC pattern and inheritance eventually break down and really make things too rigid. Most large libraries (Java & Android SDK included) that solely base themselves in this direction go towards being a "kitchen sink" or "big ball of mud"http://en.wikipedia.org/wiki/Big_ball_of_mud
You are not going to face that problem yet. I'd say things start to buckle around 500 classes.
So some tips:
- I'm partial to naming interfaces with a leading capital 'I'. This makes it obvious when looking at the file that it is an interface and not a class.
- For package naming I put interfaces and other common utility code that doesn't have dependencies using a "commons" tag in the package name. Here is the package name for IEventBus (interface):
"commons" indicating it stores interfaces, java6 to indicate language level, sdk (in my middleware efforts it's either 'sdk' or 'rt' for runtime), opencore indicating this will be a freely available package ('core' is another variation for indicating for pay), then the actual specific naming portion for the code at hand.
And one implementation of IEventBus is BasicEventBus; here is it's package:
When you have a bunch of code and even when you don't a big help in organizing is to think about module separations from the get go. At least with IDE tooling like IntelliJ Idea & Android Studio (based on Idea) there is a strong module concept in the IDE. I understand Eclipse might be a bit different, but should have a similar construct.
What I have done is aggressively modularize my middleware and am now at ~750 modules / independent IDE projects. Essentially a module should expose one main core package and a few more if necessary. You don't split packages between modules! IE don't have the same package in two different modules. The really cool thing that this does is that in the IDE and build files you can explicitly see any other modules that any given module may depend upon.
I name the modules based on the core package name exposed.
For IEventBus this is the module it is in:
For BasicEventBus this is the module it is in:
"shared" indicates that it runs on any platform where Java SE is supported; the other parts of the module name mirror the package name internally. I tail things off with "commons" so its easier to see modules that are interfaces / utility code w/ no dependencies.
So, now when I look through the entire middleware code base I have ~750 modules that are named according to package and utility areas. I've ended up now with about ~50 utility areas with X amount of modules under them. Entity system, physics, opengl, opengl es, etc. are all major groupings.
Basically you just have to get meta on organizing your codebase. With 27 classes you are fine. At some point though putting off strongly organizing your code will have a negative consequence in maintenance and productivity. So for the time being just be as consistent as possible. Depending on how long the project / effort goes and how big it gets will determine if you need to consider doing the kinds of things I describe above.
The direction I'm travelling down has been summed up in the Modularity Maturity Model:http://www.infoq.com/news/2011/09/mmm-osgihttp://www.slideshare.net/mfrancis/ibm-sponsorship-keynote-towards-a-modularity-maturity-model-graham-charters