2.11 Simultaneous Construction of Multiple Packages

The underlying precept of PL/Vision is to identify distinct areas of functionality needed for PL/SQL development (such as error logging, exception handling, dynamic SQL, etc.) and then map those areas of functionality into separate packages. In this approach, every feature, every requirement, has its place in one or another package.

The first thing I noticed as I embarked on my development effort was that I never got it right the first time. My basic idea for the package would usually be correct, but I would either not anticipate a particular need properly or I would frame the need too narrowly. As a result, I would find myself returning again and again to code that I had earlier considered finished. And the motivation for that upgrade would be to make the program more usable and reusable.

I soon discovered that I would rarely work with just one package at a time. Instead, I would enhance multiple packages simultaneously. This approach minimized redundancy and enhanced the base of reusable code. I step through an example scenario below to make this process more concrete.

Suppose that I am building an order entry system. I have previously constructed some generic packages to do string parsing and to perform analysis for on-time shipping. I decide in advance that I will have a separate package for all of my application's constants, and one package for each of my tables (orders, line items, etc.). I begin to construct my application. Every time I run into the need for a new constant (for example, if status of order is C or closed), I open up the constants package and add another named constant. I then reference this identifier in my program and avoid hard-coding.

I find that I am using PL/SQL tables to manipulate date information. Instead of repeating the code to manage these tables in all of my different programs, I create a separate package. I need to perform some complex parsing on the address for an order. My string-parsing package does not handle this requirement. I face a fork in the road: do the parsing I need specifically for the address and bury it inside the order entry program or make this program as generic as possible and put it in the string-parsing package. By choosing the latter option, I not only implement my order entry application, but also build up the robustness of the string-parsing package.

Rather than work in any one package, I might find myself adding functionality and content to as many as three or four packages in the processing of implementing one program for my application. It might take a little bit longer to finish that one program, but when I am done I will have strengthened my overall PL/SQL development environment. As new challenges appear, I continue to add to this base environment or library and also pull from this library prebuilt programs that allow me to get the job done faster (see Figure 2.5).

Figure 2.5: A parallel build approach to package-based development

If you develop your applications using this approach, you will one day reach critical mass. You will find yourself creating very sophisticated and rich new programs by doing little more than linking together a series of high-level calls to prebuilt package programs. The PLVcat package that catalogues PL/SQL code is a good example of a critical mass package. It performs some very complex processing, but it is a very small package. Its procedures consist of little more than a series of calls to other PL/Vision utilities.