in reply to OO/Application Framework question

Ovid has the right solution, given what you've laid out. There may be other considerations, but you didn't tell us what they were. :-)

To continue further, doing what Ovid has described requires that you be willing to do this kind of analysis of your requirements. However, if it's an application of any reasonable complexity and/or lifespan, the cost of the time spent doing this will be realized over 100-fold during the first 6 months of development. (And, no, that's not an exagerration. If anything, it's a very conservative estimate.) The very fact you say raving mess of a question means that you feel you don't have a very good understanding of your requirements, let alone how you want to go about designing it. To me, that's a very large blinking red flag that my development effort is going to be marred by cost overruns, late deliveries, and a large ulcer. Personally, I think those are all things to avoid. But, Slavercise has been in the news lately, so go figure!

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Re: OO/Application Framework question
by joeblow (Novice) on Apr 17, 2003 at 23:37 UTC
    Hiya dragonchild,

    I understand the requirements perfectly, as they been expressed to me within a tight set of rules. Yet I want to make the development easier on myself, and experiment at the same time :) The whole system has already been finished in the typical CGI-type environment, yet as ever, TMTOWTDI, and I'm looking to compress those scripts down into modules, and execute it from just a base script. Just to simply speed the whole operation up.

    best,

    >joe

      As you've said, the system is already up and running, so, obviously, the business owners have approved your translation of their requirements into reality. And, frankly, you can stop there.

      However, I feel that, if an application is to be maintainable, it needs to be as decoupled as possible. To safely decouple something, you need to understand the business logic behind requirements. You need to be able to identify those things that seem to be popping up in the system with alarming regularity. You need to be able to identify those infrastructure features that would be really neat to have, but don't do add a single whit of functionality to the system as it stands. And, beyond all of that, you absolutely have to have the fire in your belly that makes you want to make it as beautiful as it can be.

      If you're missing any of those things, don't read any further, cause what I'm going to say doesn't apply to you.