Some Personal Remarks on Object Orientated Programming:

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

iii. Fail-Safe:

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

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

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 called "Prototyping".

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!

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.

C. Metaphors and Models: (Subjective Programming)

The computer is often used to explore structures "metaphorically" via simulation and modelling -however, perhaps the machine itself can also be seen 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 in more general, philosophical and abstract terms.

-Domains and Definitions
-Structural Hierarchies
-Translation (Mapping. Interfacing)
-Evolutionary Metamorphosis:

Some Personal Remarks on Object Orientated Programming:

(Notes on OOP in Java):

1.0 Some Basic Characteristics of OOP:

2.0 Some Basic (Philosophical) Implications:

3.0 Some Basic (Practical) Concepts: