|
Special Series
Building a Code Analysis Utility for PL/SQL
In this 8-part series, Steven Feuerstein, one of the world's leading experts on PL/SQL (and an OTN Member since 2001), explains how he created OverloadCheck, a PL/SQL utility that relies on information in the data dictionary to analyze packages for ambiguous overloadings.
Steven Feuerstein is one of the world's leading experts on the Oracle PL/SQL language. He is the author or coauthor of nine books on PL/SQL, including Oracle PL/SQL Programming, Third Edition, and Oracle PL/SQL Best Practices (O'Reilly & Associates, http://oracle.oreilly.com/). He is a senior technology adviser for Quest Software, has been developing software since 1980, and worked for Oracle Corporation from 1987 to 1992. ).
|
Download overload_check.zip
Part 1: Building a Code-Analysis Utility and Doing It Right the First Time
In this initial step, Steven discusses what's involved in creating a utility, how to perform the required analysis, and how to translate the results of that analysis into a useful form.
Part 2. Getting Started, Starting with Testing
Steven explains how to save time by setting up a test plan before you write a speck of code.
Part 3. Creating a High-Level Design
Ready to start coding? Hold your horses: you need to establish a design first.
Part 4: Implementing OverloadCheck: The Construction Phase
Time to spec your code packages, piece by piece.
Part 5: Adding Smarts to the Argument Information
Steven gets into the details about hiding the complexities of multi-level and string-indexed collections.
Part 6: Crafting Service Providers: Packages with Focused Functionality
A look at the lower end of the hierarchy of OverloadCheck software, the domain of relatively small, focused units.
Part 7: Crafting Service Providers: Creating a Versatile Reporting Package
Find out how to streamline code with the dynamic WHERE clause and
how to put a user-friendly wrapper around unwieldy-but-useful
procedures as you explore the creation of OverloadCheck's
reporting package.
Part 8: Getting it Right the Second Time
In the final stage, Steven uses a test engine and his predefined test cases to do some testing. He also shows how to use the process of refactoring to fix problems and improve the inner workings of the program.
|
Bookmark
