I tend to use a lot the incomplete framework aproach and has been a very wise decision from day 1.
Take this for example: I work creating mobile games (SMS, WAP, MMS and J2ME), for the SMS games (our biggest market at the moment) we created a framework that has already defined a lot of the common issues in this environment (connect to the mobile service provider, handle the player's load on memory, handle user interaction, etc), but the actual implementation must be provided by the project itself.
You end up with a lot of "final" classes that must be used as is (standard components as administrative servers and monitors), some "normal" classes that can be extended and modified by the developer (statistics gatherers can have a lot of similarities between games, but some times you need to make small adjustments) and some abstract classes that must be provided by the implementation (define the Business Logic of the whole system).
When you plug all that togheter you have a balance of a semi-abstract, efficient (you can optimize a lot of tasks) and maintanable system. When you start with one simple project it may look like a lot of the work could be spared, but when you have 30 or 40 independant systems running the maintenance and update process is a lot simpler. |
java.net RSS Feeds
