Introduction to SAS Object Programming

Object programming in SAS is very different from Base/SAS and Macro.

I found the transition from Base/SAS to object oprogramming was mostly a mental evolution. The evolution began during the Dot-Com era when I realized that SAS manuals are the best in the world when it comes to command and syntax explanation; however, SAS manuals are the worst in the world when it comes to application structure and design patterns. Search every SAS manual ever printed, you will find nothing on the topic of application structure. SAS manuals were designed for people who perform adhoc data analysis.

Object programming is for systems development, where there is a need to have SAS analytics upgrade with controls and structure. Object programming has commands, functions, and code structures that do not exist in Base/SAS or Macro. This new structure has a duel purpose. One purpse is to create wrappers that encapsulate and protect each logical step written in Base/SAS. The second is to create a relationship between each structure at runtime.

Object programs are specifically written so the application exists as a library of procedures that are compiled at development time, but are assembled into a fully working application only at runtime. The library of procedures consists of all the required steps that must be part of the application, optional procedures that can be included based on data in the data stream, and optional procedures that can be selected by the software user. While this seems contrary to the way computer science people learn how to program, dynamic assembly provides the key advantage that drives Microsoft and others into restructing the way compiler work.

Software that is dynamically assembled relies on a external list of programs that defines every program used in the current session. For most SAS programs, this external list will rarely change once the app is in production. For advanced applications, the external list may change for each session and content may be different when parallel SAS sessions are in play. Adding new programs to the Application Definition List provides an easy way to insert new blocks of code anywhere in the existing process. During the test and QA time frame, programs that perform permanent database updates can be disabled or removed from the Application Definition List.

Developer Advantage

Error checking routines and can be inserted before/after and inside each SAS object without changing any of the validate source code that is currently used in production. This eliminates an entire field of potential errors that originate during development.

IT Manager Advantage

Every logical step can be setup with multiple validation routines to ensure that every possible data condition is automatically tested. As other portions of the application change, auto-testing for expected and actual results will identify unexpected results before the application is deployed back into production.

Client/User Advantage

Non-technical people can add and removed business rules, by mouse-clicking program names in the Application Definition List to indicate which programs are active or inactive. Statistical models can be in parallel, the idea here is to accellerate data mining and "what if" testing on expected results.

Parallel Processing Advantage

Code that works in singular mode also works in parallel mode. When running SAS in parallel mode the entire application can be duplicated any number of times, the only code difference would be a top-level controller that links and controls execution of each parallel copy. Programming for parallelism and check-point recovery become critical when SAS/Grid is in use.