Skip Rewriting the Same Code — Standard Code, Abstraction, and a Root Interface (3 Viewers)

[GPGeorge]

The video from Eric Blomquist's April 2nd presentation of his Access Root Interface and Object Superclass Framework for the Pacific chapter of Access User Groups is now available on YouTube.
Links to articles further describing them are in the video description.

Eric Blomquist walked us through a demo and illustration of the development structure he uses to share code across forms and across applications.

His framework is built on a comprehensive set of superclasses that leverage a core foundation which he calls a Root Interface.

The core idea: a naming convention rigorous enough that code can identify any object by entity and type at runtime — which means objects can be passed as parameters and code can act on them without knowing in advance which specific form or control it’s dealing with. Layer in consistent design patterns for common form functions, and you have a root interface: not a formal documented structure, but a reliable contract that your code can be written against.It all comes to live in a Framework of standard code, made up classes and superclasses.

Want to learn more about Eric's Root Interface and Framework? Here are links to the foundational articles on Reddit.

Foundations - An Access Root Interface

Frameworks: An Object Superclass Framework
Additional download files for Eric's presentation and PDFs of the two articles, are available at our AUG chapter website, where you can also sign up to be notified of future meetings.

https://accessusergroups.org/groups/pacific/

 

[The_Doc_Man]

I did not view the presentation, but I recognize something here.

The core idea: a naming convention rigorous enough that code can identify any object by entity and type at runtime — which means objects can be passed as parameters and code can act on them without knowing in advance which specific form or control it’s dealing with. Layer in consistent design patterns for common form functions, and you have a root interface: not a formal documented structure, but a reliable contract that your code can be written against.It all comes to live in a Framework of standard code, made up classes and superclasses.

Any of you familiar with the product called PeopleSoft will recognize a similar concept to the description of that core idea. It is a common enough topic that we have occasional "hits" on the subject of data-driven applications - things that handle a lot of management bookkeeping just by knowing what it is that you are managing.

A practical strength for such products is that if you have classes built up for the most common objects, a lot of functions can be defined that are either completely or at least mostly handled within the classes. Putting together special details to form a coherent app becomes a lot easier since you have a lot of the work already done.

A weakness for such products is that if you have a LOT of objects eligible to be treated as members of a class, but you don't have classes for EVERY such object, you run into implementation difficulties. Either you need to do a lot of catch-up programming (that is rarely inexpensive) OR your magnum opus becomes a tail that wags the dog (which customers really don't like).

For anyone who wants to see some news articles about this weakness and what it does to projects, look up DIMHRS, which has multiple articles in news articles, including a Wikipedia history. It is a perfect example of starting a project with an inadequate set of object classes and the need for a LOT of expensive retrofitting.