Object orientation has a design paradigm suite called SOLID. I propose ‘LIQUID’, a design paradigm suite for information orientation.
- L. Levels: RDB,data,info,ontologies
- I. Indirection of fields
- Q. Query retention
- U. Usability/UI at every level
- I. Information defined organization
- D. Drill down, vertical architecture
L – Levels: RDB, data(OO), info, ontologies – Applications should be composed in levels. Each level can interact with all of the levels below it. And each level has its own design principles, for example SOLID at the data/object oriented level. One level is the correct level for each need.
I – Indirection of fields – members of objects should be identified by information, not code, i.e. not within structs, or as class members.
Q – Query retention – The queries used to create the result sets need to be stored as part of the result sets.
U – Usability/UI at every level – each level should be usable by the one above and uses the ones below. Debugging/user_interface can start at any level. Levels identify themselves.
I – Information defined organization – Information should be used to distinguish ‘subclassing’, ‘graph relationships’, ‘hierarchies’, ‘DB relations’ etc. rather than inheritance. Each layer still has its ‘native’ organization, however.
D – Drill down – Vertical architecture lets the user drill down into program in order to interact with it, rather than having architecture composed of UI/midtier/Data layers through which the user generally can not drill. Expansion may consist of vertical integrated plug-ins.
The relationship of SOLID and LIQUID
SOLID is used as part of LIQUID wherever the needs of the software are best handled by object orientation. This results in hybrid object/info oriented systems. So LIQUID is not really an alternative to SOLID. LIQUID incorporates SOLID when needed. SOLID does not apply to information oriented work however, except at the data(OO) level:
S – single resp NO , resp encapsulation MAYBE, the problem is that information gets used everywhere and if you change it you must change it everywhere
O – open/closed NO , [INHERITANCE NOT USED, CLOSED FOR EXTENSION, SUBCLASSING SIMULATED BY INFO INTERPRETATION], open for modification, leads to perfection
L – substitution N/A, [INHERITANCE NOT USED, CLOSED FOR EXTENSION, SUBCLASSING SIMULATED BY INFO INTERPRETATION]
I – interfaces NO , prevents drill-down
D – dependency inversion MAYBE – normal dependency of high level upon lower-level components limits the reuse opportunities of the higher-level components
The second I in LIQUID refers to the following situations
– graph – A -> B [is a]
– subclass – A .. B [inherits from] information ‘subclassing’ through information parameters and implementation
– hierarchy – A: -B [has a] information ‘grouping’ through some generic structure
– list – A – B [after a] lists orderable by information
– RDB – A -< B [relates to a] table/column is addressable and characterizable, and business-rule-able
Data and Information
Object Orientation is the best when working with data. There is a huge difference however between data and information. When working with information, it seems that the opposite of SOLID applies, escpecially the O)pen/closed L)iskov and and I)nheritance parts. Part of the reason for this is that with information oriented code, relationship is managed through data rather than through code organization. Members of objects/classes and sub-classes of classes are the organizational elements in OO that I am referring to. LIQUID stands for Levels by need, Indirection of fields, Query rentention, Usability/UI for each level, Information defined organization, and Drill down through vertical architecture.