So far this book has concentrated on using Java with a minimal coverage of the underlying theory. This is based on the assumption that most people learn best when doing rather than thinking. I have no time for the attitude that writing code is a trivial activity done only by code monkeys, programming is a creative and absorbing pastime that is inherently intellectually demanding. However every programmer should be able to see the bigger picture needed by software architects and system designers. From an organisational perspective creating software is very expensive. Some projects have cost tens of millions of pounds and yet been abandoned without success. In the early days of programming languages the main objective was simply to allow programs to be written. Once that task was achieved the focus moved on to allowing the management of complexity.
When i first started programming I thought that the people who created commercial software must have been geniuses, people of an entirely different level of intellect to myself. Over time I began to appreciate that much of what they achieved was not due simply to raw intellect or ability but due largely to the management of complexity. A great engineer such as those behind new aeroplanes or civil engineering projects will generally not have an intimate knowledge of every nut, bolt and rivet of the system, but will understand the systems in generalised overall terms. Other designers and engineers will have a more intimate knowledge of each subcomponent. It is very important to understand the underlying theories behind the language, as it can have a big effect on how you design and create your own programs, and it can help you understand the thinking behind programs by other people, and the reasoning behind the decisions of the overall architects of the system.
A brief history of objects
The designers of Java set out with the idea that it would be used for substantial software engineering projects involving multiple programmers and designers. As a result it supports features that are easy to overlook if you are new to the language and writing your first programs in isolation. If this chapter seems overly theoretical and abstract, bear with me as the ideas it contains are very important to the wider world of software engineering.
Object Oriented programming is the latest in a series of efforts to make programming easier by dealing with its inherent complexity. The first to major steps in language developments was first the move from assembler to high level languages. Assembler required an understanding of the CPU architecture of every machine that was being programmed. If you think that the speed of a modern CPU is measured in Mghz or millions of cycles per second, whereas the speed of the first IBM PC was measured in terms of thousands of cycles per second, you can appreciate how important raw performance used to be.
The limitations of assembler This made programming a complex task, but it did get the maximum performance out of the system. The move to high level languages meant languages could be portable across different hardware systems and they were designed to be more like human languages rather than computer languages.
The next major step was the idea of structured languages where complexity could be managed by breaking the program into discreet chunks of functionality by the use of functions. Functions are named pieces of code that could be regarded almost as discreet separate programs.
Object orientation is the latest concept to manage complexity in programming, and it does this by attempting to tie code and data together so that objects (instances of classes) “send messages” to each other. I find the use of the term “sending messages” to be rather distracting and I regard methods as the OO version of functions in structured programming. This may simply reflect my background in structured languages such as C and Pascal rather than any reflection on the nature of Object Oriented concepts.
Java is one of the more recent in a long line of Object Oriented programming languages. One of the earliest and most influential was SmallTalk which was developed at Xerox park in the late 1970's. Smalltalk never reached commercial critical mass, but the C++ language developed at AT&T Bell Laboratories by Bjarne Strousjoup became a huge success. This was partly because it built on the syntax of the C language which was the de-facto standard for low level programming. C++ is a hybrid language which can be used to write in the older procedural way, or in the Object Oriented style. In a similar way that C++ was an extension of C, Java was modelled on C++. Unlike C++ Java was designed to be truer to the ideal of Object Orientation.
The use of OO in languages generally as a performance overhead, but by a combination of optimisation and the increase in hardware performance this has been largely offset.
The C# language created by Microsoft borrowed many of the ideas in Java and attempted to improve on it. People who have programmed in C# say it is similar enough to Java to make it easy to switch between the languages.