Suggested Philosophy-Based Pattern

As mentioned, we would like to find a philosophical model that will replace the current one, which will reduce the amount of connections between software application entities.

At first glance, the Monadistic model certainly appears to be a good candidate for the job. The idea that all things in nature are made of the same building block – the Monad, which stands for itself, and therefore, its existence do not depend on other Monads, is perfectly match our expectation from the alternative model that we seek for – reduced number of dependencies.

Let’s see how could we “transform” the Monadistic model into a software model. The first thing that we need to do is to point out the software entity that could be defined as the Software Monad.

The smallest conceivable candidate would be the Object class, which serves, in development languages such as Java and C# as the base object for all other objects. Some of its characteristic appears to be relevant:

  • It is lighter than a feather - it contains neither information nor functions, which are valuable in a direct manner to any application, and therefore, it could be classified as none-tangible entity.
  • It doesn’t depend on any other class.
  • The whole application is made of Object class instances, since each class that is used by the application is, by definition, also an Object class (all classes must inherit from Object class).

Without a doubt, those characteristics makes the Object class a perfect candidate to be nominates as the Software Monad.

But does the Object class satisfy our needs from a Software Monad? It seems that even though the Object class does contribute a decisive contribution to fundamental object-oriented programming functionality (activities that demand ignoring the real type of an object – storing, transferring and such), still, from the point of view of the applicative functionality, the Object class is in fact meaningless. It doesn’t have anything to do with the application’s domain nor with the application’s infrastructure (GUI, communication, storage, etc.), and therefore, it cannot be used as a basis for application-level Monad.

Another candidate, probably the largest we can think of, which still could be thought as the Software Monad, is a group of classes  that handle  a particular use-case or task within an application  - for example, tasks such as opening a new file, saving a file or  searching for a string, which are all integral parts of a word processing application. Such a group of classes, which we may call a Task-Oriented Classes Group, is obviously not the perfect candidate for being the Software Monad, as the Task-Oriented Classes Group is certainly not “weightless”, as a Monad should be, but still, the fact that the Task-Oriented Classes Group does not depend on outer entities, and the fact that, everything there is in an application is eventually assembled from such groups, and nothing else, enable us to consider it as legitimate candidate.

The problem with treating the Task-Oriented Classes Group as a Monad is the redundancy that it will cause. In order to maintain he Monad’s independency, we should add to it everything it needs to function independently. The redundancy that will occur as a result is obvious - for example, continuing with our word processor sample, we should hold a separate document model - paragraphs, sentences, words, styles, etc., which is actually the application’s Business layer, for each one of the Task-Oriented Classes Groups (our monads), and we certainly wouldn’t like to have a separate set of DB tables for each of our Monads.

Thus, since both options, the Object class and the Task-Oriented Classes Group, were disqualified for practical reasons, it seems that we'll have to look for the Software Monad, somewhere between the Object class, and the Task-Oriented Classes Group.

But is it possible to find an entity on the axis between the Object class and the Task-Oriented Classes Group, which we still could be called a Monad? It is clear that any selection, of any point on that axis, will force us to give up on the most important quality of a Monad – its independency. Since if we’ll take a step forward from the Object class edge, we will find ourselves with a class which is by definition depends on the Object class (all classes inherit from Object class). And if we’ll take a step backward from the Task-Oriented Classes Group edge, we surely will have to give up on some of the classes, which are necessary for the completion of the said task, and therefore, what we will have in our hands is an entity that depends on outer entities. The conclusion is clear – no entity between the Object class and the Task-Oriented Classes Group could be called a Monad.

It seems that the only way to move toward an alternative model would be to give up our aspiration to find a Monadistic model and try to find a model that will integrate both the Monadistic and Monistic approaches.

In order to understand where we should draw the line between the Monistic part and the Monadistic part, I think that we should examine each one of the current layers.

  • User Interaction – At first glance, perhaps due to the almost tangible aspect of it, it seems like that the GUI layer is a single solidity, which making it very difficult, maybe impossible, to identify Monadistic entities within it. Let's see if this is actually the case.

The GUI layer is composed from two sub-layers – 

    1. The Control sub-layer, which contains components designed to provide the user with a tangible entities, enabling him to execute the application’s functions of the system, including buttons, menus, toolbars, etc.
    2. The View sub-layer, which contains components designed to display and edit information. These kind of components are usually working area components, which contain the proper means to display text, images, spreadsheets, etc., and in many cases, also the means to edit the displayed information.
Typically, each component of the Control sub-layer will be designated to a specific task - open a file, search for a word, etc., but still, components that share some major attributes, or functional goal will be grouped together in “geographical” entities such as menus (File, Edit, View, Tools, etc.), toolbars, etc. Similarly, we may argue that the View sub-layer components are also sharing “geographical” entities. For instance, the two View sub-layer activities mentioned above - open a file and search for a word, are using the same component view – the working area of a textual application, as the arena of their activity.

The fact that both sub-layers are assembling related activities under a certain “geographical” component, may lead us to the following idea – both User Interaction sub-layers, should be divided within themselves into two different parts:

    1. The Monistic Part - which serves as the basis for all activities, and is equivalent in some manner to the collection of all “geographical” entities that reside in a specific application, and therefore, it is the applicative part. Since this part content is mainly consists of GUI containers, we may also refer this part as the framework part. The framework enforces a set of rules and behaviors upon all the monads that it carries.
    2. The Monadistic Part – which consists of a set of monads.

How does it work? Let’s say that the Monistic (framework) part contains a “File” menu. A generic framework is receiving registration requests from monads such as “open file” monad that does not contain any information about its GUI appearance, not even the fact that it should be displayed as a menu item (since, as a monad, it shouldn’t have a “body”), but just functional (what to do?) and a descriptive information that should help the framework to determine its shape. When such a request is received, the framework knows, according to its built-in rules and the descriptive information it got from the Monad, what actual “body” to produce, and where is the right place to locate it within the application’s GUI.

  • Business – this layer, by its definition, is supposed to maintain a reflection of the domain that the application deals with. But since the potential number of reflections is not limited, both in scope (we might argue that the list of all subscribers of a telecom company , with all their personal details and all their bills and conversations details is a legitimate reflection, but we might also argue that the personal details could be omitted ) and structure (we can decide that all the aspects of a telecom company subscriber will be represented in a single class , and alternatively, we can set up a cluster of classes that represent those aspects as well), we can refine the definition of the business  layer and argue that it should maintain only the reflections that truly serve the Interaction Layer. Since at least some of those reflections serve more than a single Interaction Layer entity (for instance, in a word processing application, the Business Layer object that maintains the file text, will serve a large collection of edit and search activities), it seems that there is no choice but to declare that the Business Layer should stay Monistic by its nature (simply because the reuse of Business Layer entities makes it impossible to find distinct Monads in that layer).

But if we will deepen our investigation, we will find that the reuse of Business Layer objects (by the Interaction Layer objects) is usually related to the information that resides on the Business Layer, and hardly is related to its functionality (usually, each Interaction Layer object is using its own Business Layer functionality). And therefore, it seems that we could create the desired separation – a Monistic layer of objects that manage the information (including of course methods to approach this information), and above it, a Monadistic layer of decoration objects (see GOF’s Decoration pattern), that from one hand, draw the information they need from the Monistic layer (that handles the information), and from the other hand, provide functional services to the Interaction Layer objects. The Monadistic nature of such a layer is clear – the applicative structure doesn’t depend on the existence of any of its contained objects (Monads), and we could add or omit such object whenever we like, without harming any of the application’s activities.

  • Data – it seems that any attempt to find a Monadistic side in this layer is doomed to fail, and therefore, it supposed to stay Monistic by its nature.
An integration of all the above will probably lead us to the following conclusion – the Monad that we are seeking for, is an assembly of Interaction Layer objects (both Control and View objects) and Business Layer objects (functional objects only). These Monads are integrated into an apparently solid Monistic structure, constructed from the Data Layer (that haven’t been changed), information-related Business Layer objects, and the “geographical”-related Interaction Layer objects.

Following is a UML based description of the suggested pattern:

All Monads are sharing the same infrastructure, contained in the MonadBase class.
The MonadBase class is actually a group of three classes – the MonadBase itself, which contains two more base classes, the MonadDataBase and the MonadBusinessBase. This structure is used as a base for a specific Monad, which is a pair of two classes – the MonadSpecific class and the MonadBusinessSpecific class.

  • The class MonadBase and its successors, represented here by the MonadSpecific class handle the management tasks. These classes handle the construction of the Interaction Layer objects, needed to activate a specific Monad.
  • The class MonadDataBase handles anything related to access to information sources. As mentioned, access to information source is not unique to any of the Monads, and therefore, the information handling is taking care of within shared components.
  • The class MonadBusinessBase and its successors, represented here by the MonadBusinessSpecific class, are used for definition and implementation of the applicative activity of each Monad.