Object concepts The basic concepts of the object-oriented paradigm (way of doing things) are rel atively easy

to understand and to apply. Alan Kay, the inventor of Smalltalk, had been workin g on A Personal Computer for Children of all Ages [Kay 72] as early as 1968: as his targ et was children, it isn t surprising that the basic concepts are simple. So, why all the fuss about objects? Surely developers wouldn t change the fundamen tals of software development without good reason? Some of the justifications for usin g objects might seem rather obscure at this early stage, especially if you haven t much expe rience with the techniques that came before (structured programming and structured methodolo gies). The object-oriented approach was invented (or, rather, it evolved) because of th e difficulties people were having trying to get good quality systems produced on time and withi n budget, especially for large systems with many people involved. Once you ve worked your way through this book, the justifications given below shou ld make sense and you should agree with most of them. Here then, for the record, ar e some of the justifications typically given for object orientation: Objects are easier for people to understand: This is because the objects are der ived from the business that we re trying to automate, rather than being influenced too early by computer-based procedures or data storage requirements. For example, in a bank s ystem, we program in terms of bank accounts, bank tellers and customers, instead of div ing straight into account records, deposit and withdrawal procedures, and loan quali fication algorithms. Specialists can communicate better: Over time, the software industry has constru cted career ladders that newcomers are expected to climb gradually as their knowledge and experience increases. Typically, the first rung is programmer: fixing faults (bu gs) in the code written by others. The second rung is senior programmer: writing the code i tself. The third is designer: deciding what code needs to be written. Finally comes the role of analyst: talking to customers to discover what they need and then writing dow n a specification of what the finished system must be able to do. Such a career ladder may not be a bad idea in itself. The problem comes when you realize that each specialist is expected to learn a whole new set of concepts an d techniques, depicting their conclusions using notations that are tailored to their specialty . This means that there s a big gap in understanding between the different roles, made worse by the fact that the documents are being passed down the career ladder rather than up, so we tend to have to read documents without understanding the techniques used to prod

uce them. This can lead to throw it over the wall syndrome: the analyst produces a lar ge amount of documentation, throws it over the wall to the designer and walks away. The designer, after weeks of effort, produces even more documentation, using complet ely