Suggested Philosophy-Based Pattern
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.
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.
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.
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
- It doesn’t depend on any
- 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).
a doubt, those characteristics makes the Object class a perfect candidate to be
nominates as the Software Monad.
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.
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.
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
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 –
- 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.
- 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
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:
- 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.
- 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
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.
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.
- 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.
Following is a UML based
description of the suggested pattern:
All Monads are sharing the same infrastructure, contained in
the MonadBase class.
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
- 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.