Name

PKG-03: Freeze and build package specifications before implementing package bodies.

Synopsis

Develop a “specifications first” discipline: put off writing package bodies as long as possible. Instead, sit back, relax, and brainstorm about the kinds of things you want to do with each package (based, of course, on requirements provided by the users). Write out those things-to-do as procedure and function headers in the specification. Do this for a whole bunch of packages you need to build.

Then try them out. Even if you don’t built the package bodies, you can still write programs based on the headers. By doing this, you often uncover errors in the requirements, missing parameters, and so on. Since you haven’t yet written the implementations, it’s easy to clarify what the user wants and modify the package specifications.

Once you are confident that the specifications reflect the application needs, dive into those package bodies!

Example

We are building a telesales call management system. Management just told us that due to the upcoming IPO, we have to get everything done in two months. Yikes! My first inclination is to start writing code madly, but the DBAs haven’t finished designing the tables, and the users are still thrashing. I can’t wait, though, so I take what requirements have been set and brainstorm via package specifications.

I know that I have to do some analysis, so I quickly put together this specification: 

CREATE OR REPLACE PACKAGE analysis
IS
   FUNCTION avg_workload (
      dept_id IN INTEGER) RETURN NUMBER;
   FUNCTION workload (
      operator_id IN INTEGER) RETURN NUMBER;
   FUNCTION avg_numcalls (
      dept_id IN INTEGER) RETURN NUMBER;
END analysis;

I don’t yet know how to calculate the average workload for a department, but I know I will need it. I also need to perform some call maintenance, and according to the documentation, I need to transfer a call to a new department: 

CREATE OR REPLACE PACKAGE callmaint
IS
   PROCEDURE transfer (
      call_id IN INTEGER, dept_id IN INTEGER;
END callmaint;

Now, I can perform two pieces of “magic”:

  • I can compile both specifications, since they don’t rely on any %TYPE declarations to tables that don’t exist. That way, I can make sure their syntax is valid.

  • I can write other programs that use these programs, such as the load-balancing “assign a call” procedure, shown here: 

    CREATE OR REPLACE PROCEDURE assign_call 
   (call_in IN INTEGER, 
    oper_in IN INTEGER, 
    dept_in IN INTEGER) 
IS
BEGIN
   IF analysis.workload (oper_in) < 
         analysis.avg_workload (dept_in)
   THEN
      callmaint.transfer (call_in, dept_in);
   END IF;
END assign_call;

Once again, I can verify that this code compiles (though I can’t run it). I can also walk through this very readable code and check for logical errors. Allow me to read it to you:

If the workload for this operator is less than the average workload of the department, then transfer the call to that department.

Wait a minute, that doesn’t sound right. Shouldn’t I transfer the call to that operator who is underutilized? So I check with the users, get confirmation of their mistake, and in minutes have corrected the callmaint specification and the assign_call procedure. No need to fix the package body, though, since I held off implementing it.

Benefits

By concentrating on the way that different programs interact with each other, the resulting software is better behaved and more easily changed over time.

You spend less time fixing errors later in the development cycle, since you can more easily identify problems before extensive coding has even begun.

Challenges

You might get nervous because you are holding off writing the “real” code, the package body, while the clock ticks away. The time spent on this upfront design verification will, however, save you hours of fixes and debugging later on. You can also create the package body that contains “stub” subprograms, in which each procedure or function contains the minimum amount of code needed to get the package body to compile. The code can be run but, of course, it won’t actually do anything (except perhaps allow you to trace execution and validate overall logical flow).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset