| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.misc -> Re: Best Coding Practice
Rauf Sarwar wrote:
> casey.kirkpatr..._at_gmail.com wrote:
> > General "best practice" question here, for an "inherited" program.
> >
> > There is a flat file with 9 different record types (for brevity,
RT1,
> > RT2, ... RT9). The file serves as a queue of sorts - its records
> must
> > be processed in the order they are received, independent of record
> > types. About 40% of the logic for each record type must be done
for
> > all record types (that is, 40% of the code that is exectued for RT1
> is
> > also executed for RT2 - RT9); about 20% of the logic overlaps a
> > fraction of record types (RT2, RT5, and RT6 might require the same
> > code); and the remaining 40% of the logic is unique to each Record
> > Type.
> > Most of the logic is brief; however, the code for 2 of the record
> types
> > is in excess of 3,000 lines of code.
> >
> > The current program reads a line of the file, determines the RT,
and
> > simply passes all appropriate fields for that type to the
appropriate
> > package (there are, therefore, 10 packages - the master and 9
> slaves).
> > Naturally, each slave package has the the full amount of code
> > (redundancies and all) repeated throughout - any change to any of
the
> > shared 40% of logic requires synchronized changes between 9
different
> > packages.
> >
> > Obviously, this is bad. My question is, what would be the best way
> to
> > restructure to packages?
> >
> > My inclination is to have one package, period. Have the driving
> logic
> > simply run all records through the "40% universally shared logic",
> then
> > call a sub-procedure for each RT.
> >
> > The only downside is that the more complex RT's make this package,
> > well, huge (a total of nearly 9,000 lines, even after eliminating
> > redundant code). This gives me a "bad gut" feeling that I can't
> quite
> > put my finger on: the code itself will be as modular as ever; yet
the
> > idea of merging 10 manageable packages into 1 bohemoth "feels"
wrong
> > (particularly in leu of the possibility that multiple changes to
> > different RT's might need to be worked concurrently by different
> > developers).
> >
> > My question is - is it valid programming practice to merge the
> > packages; or should I look for more of a middle-ground solution?
>
> Couple of things to keep in mind.
> 1) Write it once and use it multiple times if you can.
> 2) Keep it simple and tight.
>
> 2nd point is not always acheivable due to the complexities of the
> application logic so the next best thing is to write your code so
that
> if you leave the company for a better offer across the country... the
> poor soul who will maintain your code afterwards does not curse you
> night and day.
>
> I would extract the 40% common logic and put it in one master/utility
> package. Leave the individual and some overlapping logic in each of
the
> nine packages. This way you will remove the redundancy but also keep
> the separate packages to easily add any additional logic for each
> record type in future.
>
> Regards
> /Rauf
Right, right - I guess I didn't express the crux of my question. This application has exactly one logical external interface - a procedure which takes a couple of parameters (file location, etc.). No other application procedures should be called, except from within the application (for instance, no other application would independently call the RT1 processing logic). That was my major reasoning for wanting all of the code into a single package... so I could "hide" all of the extraneous function/procedure calls, and present a single package spec which makes this fact crystal clear.
I realize that all coding involves trade-offs, though. So, is it a legitimate trade-off to break a large package into 10 separate packages, INCREASING the complexity (or apparent complexity) of the application's external interface; in the interest of DECREASING the amount of code per file for the application?
In summary, is there a legitimate benefit to one of these two approaches?
Package A IS
Procedure MAIN;
END A;
Package Body A IS
Procedure RT1 IS
Procedure RT1a IS BEGIN ... END RT1a;
Procedure RT1b IS BEGIN ... END RT1b;
BEGIN ...
END RT1;
Procedure RT2 IS
Procedure RT2a IS BEGIN ... END RT2a;
Procedure RT2b IS BEGIN ... END RT2b;
BEGIN ...
END RT2;
...
Procedure MAIN IS
BEGIN
...
END MAIN;
END A;
(versus)
Package A IS
Procedure MAIN;
END A;
Package Body A IS
Procedure MAIN IS
BEGIN
...
END MAIN;
END A;
Package RT1 IS
Procedure RT1;
END RT1;
Package Body RT1 IS
Procedure RT1a IS BEGIN ... END RT1a; Procedure RT1b IS BEGIN ... END RT1b; Procedure RT1 IS BEGIN ... END RT1;
Procedure RT2a IS BEGIN ... END RT2a; Procedure RT2b IS BEGIN ... END RT2b; Procedure RT2 IS BEGIN ... END RT2;
 |
 |