Re3: OO/Application Framework question

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.

Requirements are what the user wants to be able to do. Frankly, some requirements I've seen don't even need a computer, let alone a fully-fledged Net-app. Requirements are driven by a business need (otherwise, there would be no money to pay you). Those requirements pre-suppose some business model. In fact, they assume and demand that business model. It is your job, as an analyst, to ferret out that model and be able to express it as a design.

Once you've done that, you can start decomposing that model into its functional parts. (All modelling does this, not just OO modelling, though OOA/D is currently the system with the loudest proponents.) I'll go with an OO design, as that's what I personally like. Each of those parts will usually correspond to a family of one or more classes. For example, you have a family of Report classes, a Company class, a family of User classes, a family of Session classes, etc.

So, you've got a bunch of class names. Big deal, right? Well, yeah! Once you figure out roughly what each family of classes is responsible for, you can start designing the system in terms of these things and not in terms of unrelated use cases. (A use case describes one (or more, but usually one) execution path through a system. In your case, every type of request that your app will deal with is implicitly a use case.)

The use cases are still (somewhat) unrelated, but are still very important. They describe how you need to string these things together in order to serve up what the app needs to be able to do. But, you're working in the business domain, not the programming domain. That's important because your problem is in the business domain, not the programming domain. However, these things are your link between the two domains.

So, you're wondering how this all relates to mod_perl. Well, you have all these modules that you load in your startup.pl. You then have a bunch of Apache handlers that call the right objects in the right order, as appropriate. Your system is tight, no duplication, and very pretty. You've earned yourself a beer! :-)

------
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.

Comment on Re3: OO/Application Framework question