Getters and Setters in Information Programming

I suspect that something like this discussion will occur once we get into doing a lot of information oriented software development. I do a lot of that however since there are no existing frameworks for it, I have to build my own framework, and since you never know what each piece of a framework will be used for you end up having a lot of getters and setters. Once information programming reaches the point where messaging becomes a major part of it, then getter/setter reduction as desciribed in this this article may apply. Or it may not. It’s too early to tell.

One distinction that may make the difference here is the D in LIQUID. D stands for drill down access and vertical architecture which is a principle of information oriented systems. It is a principle because drilldown is part of a data items information context. I don’t know yet whether this will affect the advisability of having lots of settters and getters yet.


The Promise of XML and OO

The Promise of Object Orientation

The whole point of object orientation is reuse and therefore stacking! Hard coded members for data sets break this paradigm by making classes so specific that they can not be reused much. Activated fields based on endemes can handle this problem.

The Promise of XML

The whole point of XML is that the field names are kept in the same place as the data and that a program can be written to read both the field names and the structure and the data and handle these in a soft coded way rather than a hard coded way. XML schemas break this paradigm by ‘hard coding’ the fields and structure.

Reclaiming the Promise

Activated fields based on endemes can handle both of these problem by specifying
the meaning of each field name in a way a computer can understand. Data semantics can help handle this problem by presenting knowledge representation with them as nodes and giving knowledge representation the ability to manage a soft-coded structure made of them.

Use Separation of Concerns with Information vs Data as well as Presentation vs View

Separation of concerns consists of separating one kind of code from another into different sets of code so that when one concern is being worked on, it has less of an effect on the other sets of code.

Examples of Separation of Concerns

Here are four separations of concern, three are well known, the fourth is proposed:

  1. [Presentation/UI]     and [Business logic/Model]
  2. [Business logic/Model] and [data storage/RDB]
  3. [Aspect orientation]  and [Functionality]
  4. [Information]         and [Data]

When applying separation of concerns to information concerns vs data concerns, how do you implement this? How do you implement separations of concerns regarding the information vs data distinction? What is your definition of information (vs data)?

Definition of Information vs Data

First of all, data and information are different in that information is data that has meaning. Data is data with little meaning. One way to spot the difference in real life is that usually, data comes in large quantities, whereas information is likely to be in much smaller quantities.

Information Oriented vs Data Oriented Programming

Within the realm of programming, data oriented programming works with data within a fixed context, and information oriented programming processes the context itself.  Fixed data oriented programming contexts can be things such as structs, classes, xml schemas, tables, and primitive variables and methods in a program. Each of these provides a fixed context for they data they contain. With information oriented programming, the context becomes variable. Members and portions of other fixed context listed above become variably defined fields using techniques to define the meaning of each field. An example of this is when a list of fields are each defined by an an endeme. Another example happens with knowledge representation through ontologies in which the meaning of each field is defined by relating it in various ways to other fields.

Implementing the Data vs Information Separation of Concerns

To implement the separation of concerns, the code used to define the field meanings and the code used to implement the meanings is moved into a separate section of the program from where the main application is kept. This is usually a separation of the middle tier in horizontally architected programs into two pieces. In a vertical architecture, each level is separated into framework and application code and the field definitions and meaning implementation are collected into the application code. I’m still in the blue sky phase for some of this stuff, so my opinion on separation of concerns may change over time. This is how I see it now.

Separation of Presentation vs Logic Concerns

Separation of data vs information concerns has a neat side effect. As I have been working with my test bed, I have also noticed that separation of concerns – data vs information enforces separation of model vs view (logic vs presentation) concerts .

The Biggest Challenge

The biggest challenge in implementing separation of concerns is being able to identify the difference between data and information and being able to identify which tasks, work, and areas of functionality belong to which layer.

User Interfaces at The Fourth Level

At the fourth level we have

  • layout and
  • relationships and
  • what the user wants to see and
  • how they want to see it
  • user specification of information collation formulas
  • meta information about formulas, functions, menus, and layouts
  • workflows and workflow modification

User Interfaces at the Second Level

you’ve seen those fixed L2 (OO) UI’s:

  • there is one menu structure
  • you can’t search for functionality
  • the pages are all specified with hard coded layouts
  • the information shown is calculated according to pre-existing formulas
  • data entry screens, we keep building data entry screens
  • fixed workflows

Comparing Level 2 and Level 4

OO systems are fixed, L4 system are flexible.

What if you replaced some object oriented structures with ontologies? The problem is that you then have to reinvent OO at level 4. This does not make sense. Object Orientation is the optimal solution for user interfaces.

But you still need to have level 4 characteristics for really flexible, useful, friendly user interfaces. So we will need to build systems that create a hybrid of user interfaces hybridizing L4 and L2. The user can specify L4 characteristics to be implemented automatically by level 3 and hybridized with level 2.

I don’t know how to do this. Maybe some version of the MVP pattern will work.

L.I.Q.U.I.D. as an Alternative to S.O.L.I.D.

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
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.

The Stagnation of Technology

In The golden quarter Michael Hanlon wrote “Some of our greatest cultural and technological achievements took place between 1945 and 1971. Why has progress stalled?”
Here are a few clues:

  1. The missing zero – classical civilization failed to advance for a thousand years because of the inability of these societies to use the zero. The zero is the basis for place value. and place value is the basis for modern mathematics. The missing zero lead to an inability to efficiently represent mathematical thought.
  2. Evidence of a missing link – The software development industry shows that there is a missing link from business to artificial intelligence. If this missing link existed, a large percentage of business programming would include artificial intelligence of some sort rather than the significantly less than 1% we have today.
  3. The wrong turn for computer programming/science probably came about about sometime around 1971. Computer science is probably the bedrock foundation technology for the modern world. Just as with classical civilization the inability to materially represent thought could be the reason for our stagnation. My candidate for the wrong turning is hard coded context with the Algol 68 ‘struct’.

I believe that the creation of the ‘struct’ in Algol 68 was a major wrong turning in computer science and that it stifled innovation and progress in computer science and thus the rest of the technological field. One way of looking at the struct is – hard coded context for data. Hard coded means the data contexts (members) are part of a program rather than something that can be processed by a program.

The struct has become utterly predominant in computer science, with an almost complete inability to use other more advanced approaches in modern software development. Modern frameworks, OO and SOA have institutionalized the struct.

Without approaches other than the struct, we can not write information oriented software. Information can be defined as that which has meaning. One major form of meaning is context. We are unable to embed soft coded meaning/context in computer code. Since meaning/context is hard coded we are unable to write programs that process it. Without the ability to process embedded meaning we are only able to go so far.

A few more primitive approaches still hang on such as SQL and functional programming, but these are being progressively more and more sidelined. They are being sidelined because they have severe problems with
1) storing meaning and more importantly 2) being easy to develop with and 3) the ability to cover the needs of customers and applications.

The focus of my research right now is building a framework that will allow us to work with a soft-coded version of the ‘struct’.

Signs of problems with the object oriented paradigm

Signs of problems with the object oriented paradigm.

1. Code is too bloated. code is too repetitive, code is too low level.
2. Businesses to not reuse application code, applications get rewritten instead. Businesses have contempt for continuous improvement of the application because they know they will replace it in a few years.
3. The next level of development (information) is flat out missing on the internet, the fields/professions/job titles for people that do this work do not exist.

Not that the object oriented paradigm is wrong, it just gets used too universally for too many problems
it is like a golden hammer. It works fine for data. It suffers when used for information.