Some Personal Remarks on Object Orientated Programming:
(Notes on OOP in Java):
1.0 Some Basic Characteristics of OOP:
A. Self-Contained Temporary Objects:
The ideas and practices which underlie
OOP are essentially based upon the creation of self-contained objects
-which only exist in order to do their work for you.
i. Existing when needed:
This is literally true
-because the practical implementation of the language only allows these
"objects" to exist within limits (automatically) determined by the
structure of the programme. When not required, the code is
automatically removed from memory by the "Garbage Collector". This
means that information stored by that object no longer exists.
ii. Self Contained:
Being "self-contained" means
that each "object" contains both the data and the instructions required
to deal with this data -dependant on the requirements of the object -as
defined by the programmer.
This gives the appearance of "intelligent" objects -because one
can give them commands (such as "connect me to the Internet") or ask
questions (such as "what is your current value for temperature?"). In
practice, this simply means that the programmer has thoughtfully
provided the instructions -in terms which can be implemented by the
Because the instructions are
implemented by a machine (which it is assumed has no capacity for
original thought) -ideally, all the possible problems that might lead
to a failure of the system need to be thought of in advance. So that
the machine can be instructed how to deal with them (without thinking).
In practice, much of this may have been already built into the language
itself (as in the Java programming language from SUN) -so that
operations that have a resonably high risk of failure (like
trying to open a data-file which may not actually exist) are foreced
into a structure that requires one to specify what is to be attempted
and what one must do if the attempt fails (for any reason).
i.e. "Try to connect to the internet
-if successful then continue -if unsuccessful then stop trying and
print an error message (containing as much useful information as is
required for the operator to solve the problem).
Presumably, if this system works for a machine, then it can also
work for humans who can then be used to operate complex systems -which
they do not fully understand -if they (iether machine or operator) have
been "trained" to respond to all "possible" eventualities.
iv. Mapping Between Different (Internal) Representations:
A computer system is a "complex"
thing -which is composed of many different components (presumably
including a human operator). Each of these components has its own set
of principles, characteristics and even "language".
i.e. The various Disk systems (CD, DVD, Floppy, Hard-Disk) and the
Printer probably have mechanical parts -but the monitor might be purely
electronic -while of course the human operator works on entirely
One Solution might be to convert
all the various components to the same set of principles. To a certain
extent, this is possible -the ancient mechanical printer (operating
like an electric typewriter) was able to mutate into an ink-jet printer
based on eletrostatic principles similar to a monitor. However, a human
operator cannot be modified so easilly.
In practice, there are many different systems of representation
being used within a computer system. This is even true within complex
software systems (and languages). For example, the angles of a circle
might be represented in radians or in degrees -a rectangle might be
represented by two independant positions (top-left corner and
bottom-right corner) or by a single position (which
corner?) plus height and width. In an administrative system, for
example, the wages of an employer might be confidential while their
(official) position within the company hierarchy is generally public
knowledge -so (official and unofficial) status and renumeration are
linked but not identical and must be treated differently.
Finding the most appropriate representation (so the machine can
operate with the appropriate set of rules) -and making the right
translation system (interface) to connect the various components is
part of the job.
B. Independance, Standardisation and Multi-Functionality:
i. Contextual Indifference:
In both the computer and "real
life" many different tasks require the same basic operations: Making
tea and boiling an egg all involve boiling water (with some
variations). Inputting or outputting data to or from the computer (for
a whole range of different tasks, from gaming to financial
administration or environmental simulations) can all involve similar
operations. True, these are dependant on the interface used -but the
bottom line is that a mouse operates like a mouse and a keyboard
operates as a keyboard -and these things don't usually care if how this
affects the rest of the system (unless they have specifically been
programmed to be aware of the differences in the various operating
ii Context Free and Context Bound:
Contextual indifference can be a
problem in situations where a specific context does require some form
of special treatment. For example, a difficult situation can easilly
arise if a musician sees a similarity between a computer keyboard and a
piano keyboard and therefore wishes to develop a computer keyboard
which is more sensitive to the way a key is pressed. This might involve
building a whole new keyboard system -based on entirely different
principles. However, once this has been achieved -then other users
might also find usefull applications for the new keyboard -outside the
field of music.
On the other hand, it can be useful if the system is able to
distinguis between various contexts -and so behave slightly differently:
For example, if one is using a
game programme -and activates "Open File" -then one might be
grateful if one is only offered a choice of relevant files to open -and
not be forced to deal with all the files present in the entire system.
However, even here -the bottom line is that opening a graphics file for
a video game or for a medical examination -all involve (at some level)
tasks that will be identical.
iii. Modularity and Inter-operability:
Obviously, it can save a lot of
work for the programmer(s) if bits of the programme can be used again
as components for a wide range of different tasks.
However, this does seem to lead to a possible paradox:
The more modular (i.e. independant of
each other) the various parts are -the more they can be repeatedly used
in different combinations to perform different tasks. However, the very
fact that each task uses shared components also creates an
(inter-)dependance on the various components.
This becomes even more complex -when dealing with components that fit
into different levels of structure -i.e when, for example, the same
nuts and bolts are used to construct components -which in turn are used
within other components -which may end up in entirely different
machines (suc as a motor car and and airplane).
-Do we know where to store these components (i.e. locally -or in a central store somewhere)?
-Do we know how these components might relate to similar components in future?
Perhaps, at some point in time,
the nuts and bolts used in the airplane will need to be made of
aluminium (or something else) instead of the current material.
-How does this possibility affect storage and access within the current system?
-Can we plan for the future -or not?
Because the situation keeps changing
(in largely unpredictable ways) as a result of the way the various
sub-systems develop -both inside and outside the computer system -it
seems that no single "ideal" solution is possible. However, this does
not mean that "anything goes". Some solutions provide more
possibilities for future development than others do. Paraphrasing
Orwell: No solutioon is perfect -but some are better than others .The
system designer needs to allow the system to develop
"organically" with the possibility of periodic re-organisation on
various levels -in order to accomodate essential changes. This is
However, because of the potential complexity and the uncertain nature
of the problems (on various levels) involved with setting up,
developing and maintaining a software system -it can be a slow and
painstaking but fascinating and educative process.
It seems that a programmer's work is never done -which may be nice for
business -as long as people are not too dependant on the results!
2.0 Some Basic (Philosophical) Implications:
Unfortunately, it seems that many professional programmers work as a
team and therefore only have direct experience with certain sections of
the design cycle The artist/programmer is perhaps an exception who is
involved with the entire cycle from conception to implementation.
Experience with the entire process suggests that valuable
insights can be gained -which may provide relevant conceptual tools for
applications not directly involving the computer.
A. Understanding Taxonomy (Organising Definitions):
By now it should be clear that
the way things are defined has implications for the way they are
organised. Computer programming involves the articulation of complex
systems of definition, organisation and control.
These problems are partly technical and practical -but they are
also theoretically interesting -and involve many philisophical and
aesthetic decisions with regard to the way the various components are
defined and organised.
On one level, the computer is a model bureaucratic system.
B. Multi-level Analysis:
A study of the various
components and how they can (or cannot) be used might
provide useful insights into the "gramamatical" processes which alre a
pre-condition for any system of coherent articulation.
The computer is often used to
explore structures "metaphorically" via
simulation and modelling -however, perhaps the machine itself can also
as a valuable metaphor for other processes. The machine should not be
simply dismissed as a difficult and boring "technical" thing which is
of no interest to
"normal" people -but the way the computer operates needs to be studied
more general, philosophical and abstract terms.
3.0 Some Basic (Practical) Concepts:
-Domains and Definitions
-Translation (Mapping. Interfacing)