Itroduction to Object Oriented Programming

8/8/2019 Itroduction to Object Oriented Programming

1/20

Next:3. Classes and ObjectsUp:Lecture Notes on Object-orientedPrevious:1. Introductionand Overview

Subsections

y 2.1 Java and C++ -- Mixture of Paradigmsy 2.2 The Question Again, Why OOy 2.3 Software Engineering and its Requirements and Goals

o 2.3.1 Introductiono 2.3.2 Software Crisis

y 2.4 The Waterfall Life-cycle and Structured Systems Analysis and Designo 2.4.1 Waterfall Life-cycle

y 2.5 Structured Systems Analysisy 2.6 Structured Systems Designy 2.7 Structured Systems Implementation, Programmingy 2.8 Shortcomings of Waterfall and Top-down Decompositiony 2.9 Object-orientation to the Rescuey 2.10 Key Application: Event-driven Interactiony 2.11 Cornerstones of Software Engineering and Object-oriented Systems

o 2.11.1 Modules and Data Abstractiono 2.11.2 Abstract data typeso 2.11.3 Classeso 2.11.4 The Primacy of Behaviour -- Interfaces

2.11.4.0.1 Exampleo 2.11.5 Inheritanceo 2.11.6 Multiple Interfaceso 2.11.7 Late Bindingo 2.11.8 Open-closed Moduleso 2.11.9 Design-by-Contract

y 2.12 Summary


2/20

2. Introductionto Object-oriented

Programming

The question always arises: is object-oriented programming a newparadigm?

i.e. is it based on aradically different model of computing, a totally new way of programming and thinking aboutprogramming?

An analysis of everyday meaning of the words object-oriented programmingwould lead us to

equate it to simplyprogramming with abstract-data-types. However, to achieve what is nowunderstood as object-orientation, we must add inheritance, and late binding(run-time binding).

Programming based on ADTs, without inheritance, is what is called object-basedprogramming.However, for many problems, simple object-basedprogramming is sufficient on its own.

Inheritance and late binding facilitate reuse, in the sense that software modules -- classes, orfamilies of classes -- may be extended withoutmodifying the original. Here, I use the termmodule in a general sense - to signify a fundamental unit of software; the components of a

module, e.g. functions, individual statements, should not normally be separated from the module.

The concept ofreuse is sometimes poorly defined. It doesn't mean simple use without anymodification, e.g. as in a library, or library function - that form ofuse is successfully used all the

time. Really, ease of reuse means easily extended, ormodifiedto cope with some change ofrequirements; indeed, we can also include ease ofmaintenance, since this, also, comes about

chiefly due to change of requirements.

Reuse via extension without (invasive) modification, is highly significant:

y A module which is modified must be tested (again).y What about current users of the module? How are they going to accommodate any

change of behaviour?

y In essence, a module which is modified is a new module, however small the modification.y One can attempt to avoid any modification by anticipating all possible eventual

requirements, but this turns out to be quite impossible; the only sure way of avoidingchange in a software system, including unanticipatedchange, is to ensure that nobody

uses it!

A quotation from John Vlissides (C++ Report, Feb 1997) sums it up: "I've said it before and I'llsay it again: A hallmark - if not the hallmark - of good object-oriented design is that you can

modify and extend a system by adding code rather than by hacking it. In short, change isadditive, not invasive."

We will see that the reuse concepts mentioned here are the embodiment of the open-closedprinciple (Meyer, 1997; Martin, 1996). The open-closed principle allows a module to satisfy two

apparently irreconcilable requirements:


3/20

y That, to be usable by other than just the module developer, a module must be closedtomodification.

y That to be reusable, the same module must be open to extension.Of course, I must not be seen to diminish the significance the abstraction and encapsulation

offered bysimple classes and modules. These offer great benefits on their own, and are majorengineering principles in their own right.

On the other hand, some of the greatest problems in software development lie in the illusion thatsoftware is easy to modify - after all, the very namesoftware seems to suggest malleability - like

plasticine, as opposed to hardware.

Actually, software is easy to create, and to modify, to hack together a quick solution, but only in

certain circumstances:

y The programmer is the user;y

The software development team is one person, or not much more;y The software is not documented;y The software has no impact on safety;y etc.

These can be summarised by contrasting large-scale software projects withsmall-scale andpersonal software projects:programming-in-the-small, and opposed toprogramming-in-the-

large, (Parnas, 1972).

When software teams attempt to carry out large projects using the same practices that they used

in personal software projects, the contrasts become apparent, the phrasesoftware-crisis, see e.g

(Brooks, 1995), takes on a grim reality.

2.1 Javaand C++ --MixtureofParadigms

Both Java and C++ are based on C, an imperative/procedural programming language, To someextent, bot Java and C++ are C with object-orientation extensions.

The perceptive reader will already have wondered: how are methods implemented? Surely,eventually, one must get to machine code -- which definitely imperative.

Here is they key to getting to grips with the apparent paradox, how can Java be object-orientedand procedural at the same time? The answer is that, in Java and C++, even in a strongly object-oriented design, a typical method / function is implemented in an procedural language -- most of

which differs little from C.

As a consequence of its mixture of features, it is perfectly possible to write Java and C++programs in a style that is rather procedural -- like pure C. On the other hand, both languages

permit fully object-oriented designs.


4/20


5/20

y It is cheap to buy; i.e. we hope that the software house produced it for low cost, and thatthey have passed that on to their consumers.

y That it is relatively efficient in terms of speed and performance and use of resources.Even today, you may be a little disappointed if a word-processor demands 256

Megabytes, and a 2-GHz Pentium, to run properly.y

If the software you had bought was source code, or object code you might expect it to beadaptable to some perform some task you had not envisaged when originally purchasing.

Hence, from the consumer and the producer point of view, we have recurring goals: cost,productivity, quality,schedule, efficiency, reuse.

One can lump together cost, schedule, reuse, and productivity, as simplyproductivity: how

quickly, and with as few programmers as possible, can I produce my new Internet killer-app? Inaddition, how quickly and cheaply can I extend it to run on a recently introduced Pentium III

with super-charged-MMX-12-speed-pipelined-over-drive?

Quality?

I am going to lump efficiency in with it. Quality can be defined simply as meetingcustomer expectations, (Crosby, 1979). Moreover, we can quote the title of Crosby's book:Quality is Free, (Crosby, 1979), to link quality with productivity; at its simplest, the less time

spent fixing faults, the greater the productivity.

2.3.2 Software Crisis

The phrasesoftware crisis is often used to encapsulate all the ills of the software industry,

particularly poor productivity, and thus to justify constant pleas forreuse.

Actually, there are many issues involved here; e.g. maybe software engineers are just as

productive as any other engineers. Or more so? Or, if software engineers are unproductive, bywhat standard are they measured?

Nevertheless, there is good reason to believe that some software engineering methods may be

immature, and that the techniques and practices associated with object-orientation do representprogress in the industry or profession.

2.4 TheWaterfall Life-cycleandStructured

SystemsAnalysisand Design

As well as being a programming (implementation) technique, object-orientation very much alsoimpacts on analysis and design, and hence the whole of management of software projects,

(Yourdon, 1989).

Those software projects of the late 1970s and 1980s that were managed (as opposed to hacked!),

were probably managed on the basis of some flavour of the waterfall life-cycle, and structuredanalysis and design (SSAD) (Yourdon, 1989).


6/20

Incidentally, let me add here, that while I believe that management - both project and people - isa crucial ingredient in any significantly sized software project, it is nonsense to think that good

management alone can succeed in the absence of good engineering techniques.

2.4.1 Waterfall Life-cycle

The waterfall life-cycle seems the natural way to run an engineering project:

y The project proceeds along clearly defined phases.y A preceding phase must be completed before the next starts.y Phase completion is judged by the outcome of the phase matching the requirements

defined by the previous phase. Note: where you have nothing executable, e.g. earlyphases, this is most difficult, and is usually where pretense starts, and the seeds of

disaster are sown.y Though it never mentionsstructured analysis and design, these are tacitly assumed; other

analysis, design methods may be incompatible, e.g. if analysis and design are not clearly

segregated.

The phases in a typical project are:

1. Study feasibility. Preliminary exploration of possible solutions. Take a hard look atbenefits versus drawbacks and costs of candidate solutions.

2. User Definition of System Requirement. The user documents as much as he knows aboutthe job the system must do. Often they don't know what they want, and, even if they do,

they cannot express it with any precision.3. Developer Definition of System Requirement. Developer analyses users requirement and,

performs further investigation of requirements, produces developers version of

requirements: System Requirement Document (SRD). The SRD is now a specificationand part of the contract. Prepare project plan, including costing and schedule.

4. High-Level Design. Decompose into subsystems, perhaps modules. Allocate to team orindividuals. Usually called Architectural Design or Preliminary Design. OutputArchitectural Design Document (ADD). Design tests for sub-systems.

5. Detailed Design. Decompose further into subsystems (units or components) such that oneperson can cope. Specify these subsystems. Design tests for (sub)subsystems. Outcome:

Detailed Design Document (DDD).6. Implementation coding. Code and test components - each programmer.7. Integration and Test. Components and modules are brought together to form higher level

systems. And tested. You should now have a working system!

8. System Test. Assess the quality of the system as defined in SRD, above. Simpledefinition ofquality: meets customer requirements / expectations.

9. Operations and Maintenance.Although this scheme is better than nothing, e.g. all hands to the keyboards, with no planning, it,along with structured analysis and design, has serious shortcomings, some of which were already

noted:


7/20

y Except for well understood cases, it may difficult to completely define requirements atthe beginning. Hence, prototyping is often prescribed.

y Closely related to the previous item, it is almost impossible to accommodate, at a latestage, changes to requirements. After all, the requirements were agreed and frozen in the

SRD. Some hope! However, the only software projects for which the requirements don't

change are dead ones!y It is almost impossible to fit reprogramming (maintenance), or reuse, into this format.

2.5 StructuredSystemsAnalysis

This example given here trivializes the methodology, nevertheless it identifies the characteristics

I want to examine.

Informal requirement: we need a program to manage the marks for a course. For obvious

reasons, I'm attempting to avoid the word class. When I want to talk about a class of students, I'll

attempt to stick to the termgroup. Marks can be entered as the coursework and examinations aremarked; hence, we identify the terms current marks for marks already entered, and new marksfor marks to be entered for the first time.

In the analysis part of structured systems analysis and design (SSAD), we would first identify the

environment diagram as in Figure 2.1.

Figure 2.1:Manage course marks -- Environment diagram.

That would be followed by a top-level data-flow diagram (DFD), Figure 2.2. Most real top levelDFDs would be more interesting than Figure 2.2. In a DFD, arrows represent data flows and

circles represent processes. Processes consume data and produce new data.


8/20

Data flows are defined using data dictionaries. Users of object-orientation could learn a lot fromdata dictionaries.

Figure 2.2:Manage course marks -- Level-1 DFD.

We can add further detail by exploding Figure 2.2 to get Figure 2.3.


9/20

Figure 2.3:Manage course marks -- Level-2 DFD.

The things with two closely spaced horizontal lines arefiles.

And so on with each process at one level becoming a full diagram at the next level. For example,

if there was detailed verification of input, it might be necessary to explode theInputprocess, toarrive at a number of subprocesses, e.g. four processes:

Input1 ---> Input2 ---> Input3 ---> Input4

When you get to a process which merits no further decomposition, you define its activity usingsome sort of pseudo-code, in a so-called mini-spec. Each statement in the mini-spec might

correspond to one or more program statements, or maybe to a system function call.

The idea of structured systems analysis is that the complete system requirements are captured inthe combined:

adata flow diagrams;

b


10/20

the data dictionary which describes the (flowing) data;

cmini-specs which define the smallest processes.

2.6 StructuredSystems DesignThe hierarchy of data-flow diagrams can now be rather easily used to form a (program)structure

chart. From the example above, we can produce a structure chart as in Figure 2.4.

Figure 2.4:Manage course marks -- structure chart.

Figure 2.4 gives a top-down decomposition.

2.7 StructuredSystems Implementation,

Programming

Implementation in code is now a straightforward matter. There is a main program, which

corresponds to mainProgram and what it calls is based on the structure chart, which in turn wasbased on the level-1 data flow diagram Figure 2.2.

int main(){

//Declare variables.

getCurrent();

validateCurrent()

inputNew();

validateNew();


11/20

makeReport();

return 0;

}

The structure chart decomposition ofinputNew is reflected likewise in its code:

voidinputNew(){

// Declare local variables.

inputFun1();

inputFun2();

return;

}

IfinputFun1, ...are at the bottom of the hierarchy, their code is developed from whatever isspecified in theirmini-specs. Otherwise, we go further down the decomposition.

Typically, procedures at each layer are arranged in libraries.

2.8 ShortcomingsofWaterfalland Top-down

Decomposition

Firstly, we must give credit where credit is due: the waterfall life-cycle is an awful lot better than

nothing. When I started computing in the 1970s is wasn't widely known or practiced, and,certainly, when I became aware of it, it solved a lot of problems, and was light years of progress

over: lets start programming at the beginning, and keep going until we're finished!

The waterfall project life-cycle and top-down decomposition are so intertwined that use of onemore or less demands the other. Hence we can discuss their shortcomings together, although this

means that we are intermingling technical, managerial, and social issues:

aFor any significantly complex problem, it unlikely that it will be possible to agree onexact requirements at the beginning of the project.

bReal systems have no top (Meyer, 1997). This is true in many systems: concurrent

systems, any system dependent on the graphics-user-interface (GUI), see the discussionbelow on event-driven systems. In fact, instead of the top-down and library structure,

what is more suitable is aframeworkorupside-down library (Budd, 1997a,1999b).c

Although the components of the top-down decompositionseem to be independent anddecoupled -- and hence we would expect that changes to one, would affect none or very

few of the others - this is far from the case. They may in fact be tightly coupled via the

(effectively) global data owned by mainProgram. This coupling is all the more damaging

for its subtlety -- you don't know it's there until you start to make changes, and you haveno plan of escape from it's grasp.


12/20

The insidious coupling -- via data -- is shown in Figure 2.5.

Figure 2.5: Coupling via data.

2.9 Object-orientationtothe Rescue

Figure 2.6 shows part of a solution based on an object-oriented architecture. Here we have the

problem (and the solution) modelled using objects. The objects have internal hiddenstate (data)and external visible methods (interface, interface functions).

For example, a StudentInfo object might have a String name an array ofdouble marks[10].The CourseReport object might be a bit like a spreadsheet and have names and summary marksfor each student.


13/20

Figure 2.6: Object-oriented architecture.

The program proceeds by (or in our object-oriented model proceeds by) objects communicating

between one-another via their methods. Data are sent via methods, data are requested andreturned via methods. Typically, data are wrapped up as objects. This execution of an object-

oriented program is shown in Figure 2.7.


14/20

Figure 2.7: Program executes via message passing.

A classissimply ablueprint / planforanobject.

2.10 Key Application: Event-driven

Interaction(Foley et al., 1990).

Traditionally programmed interaction works as in the following:

begin

Prompt user;

Readinput;

Do processing;

Display result;

end;

A little thought will indicate that this will not work for any GUI (graphics-user-interface) like

Windows, nor, indeed, for any direct-manipulation interface:

y What do you prompt? the user can do any of a large range of actions; the user is incharge, not the program.

y What input device do you read? Any of a number (mouse, keyboard, other pointingdevice) may be legal, and appropriate.


15/20

y What do you expect to read? A number? A character string? etc...The basic structure of most Macintosh application programs (and probably Windows too) is asin:

begin

Initialise; -- build windows on screen

While (not Done)

SystemTask;

if GetNextEvent(eventMask,theEvent) -- an event froma queue

HandleEvent(theEvent); -- e.g. mouse button press

CleanUp;

end;

Event driven input-output

The important point is this: HandleEvent (the application part) is driven by the event - from theuncontrollable, unpredictable user, not the other way round.

For example this can allow an interface to be mode-less: the program identifies the mode fromthe event.

It is difficult to identify any Top in such a system. The top-down decomposition can be done withonly extreme difficulty and with extreme prejudice to the system architecture and any thought ofextendibility or reuse.

Budd, (Budd, 1997a) points out the complete contrast between a top-down architecture and the

frameworkorupside-down libraries architecture favoured by the likes of our event-driveninteraction example. He uses the term upside-down library to highlight the contrast, as follows:

y In a top-down architecture, programming is concentrated on provision of the mainprogram and the higher layers. The lower layers are more likely to be provided by system

libraries: input-output, string manipulation, etc.y However, in the event-driven interaction example, the main program - theframework- is

the same forallprograms. It comes with the system - like traditional libraries used to. It

is the lower-level functions, like HandleEvent that must be programmed.

Hence, upside-down library -- the library is at the top, though not in the simple sense of top-down decomposition.

It has been said that, had it not been invented before, object-oriented programming would have

had to be invented for construction of GUIs.

2.11 CornerstonesofSoftware Engineering

and Object-orientedSystems


16/20

Already, see section 2.3, we have identified quality, re-usability and productivity as key goals ofsoftware engineering.

We have produced some samples and evidence to indicate that the re-usability and productivity

goals ultimately demand architectural design techniques and languages that produce

decentralised designs, comprised of modules which communicate with other modules via well-defined, narrow interfaces, (Meyer, 1997). As pointed out by Meyer, this is strongly suggestiveof an object-oriented approach.

2.11.1 Modulesand Data Abstraction

Systems engineering has long understood the benefits of abstraction and modular design,especially for large complex systems. The systems engineering concept of the black-box is

archetypal abstraction: the (sealed) black-box has some inputs, and some outputs that are clearlydefined functions of the inputs. The designer who employs the black-box as a sub-system is

concerned only with the function provided, and with the allowable range of inputs; he is

absolutely entitled (and obliged) to consider only the external behaviour of the sub-system.

Although abstraction in software was already well accepted in the form of high-level languages

and subprogram libraries, (Parnas, 1972) gave the first persuasive argument for softwaremodularisation on the basis of data structures (data abstraction); he also pointed clearly toencapsulation - software's version of the sealed box - when he identified the crucial (but subtle)

importance ofinformation hiding: the user of a module benefits from knowing just enough to usethe module, the provider of the module benefits from knowing just enough to implement the

module. More knowledge on either part can only increase coupling and, hence, complexity.

2.11.2 AbstractdatatypesA data type, such as the native data types int,float, ...is characterised by:

1. A set of values - that can be assumed by objects of the type.2. A set of operations that can be performed on objects of the type.

Clearly, internal representation should concern only compiler writers - the type is a sealed black-box.

I hope it will be clear to you already that any language with a modicum of type checking does

not allow objects of native types to be accessed via theirrepresentation - just via their definedoperations.

The ADT concept can best be described by proceeding from the notion of a type; moreprosaically, it is a user defined type that obeys the rules of a type set out in the previous

paragraph - particularly that users interact with the objects strictly via the supplied operations.

2.11.3 Classes


17/20

Object-oriented languages have special modules, usually called classes, which are specificallyused for defining ADTs.

Objects are instances of classes. That is, objects are to classes what variables are to types: in C++

or Java, int i; defines the variable i, an instance of the type int.

Syntactically, classes are likesuper-records (using recordto mean a collection data structure

without any coupled methods/definition of behaviour). In addition to data, they containoperations - in the form of functions. Normally, the data (representation) part isprivate and so

inaccessible to user programs. Interaction with the object must be via thepublic operations:

y Private data, public interface functions.y Private representation, public interface.y An object should be characterised entirely by its behaviour

2.11.4 ThePrimacy ofBehaviour-- Interfaces

If users of a class concentrate on the behaviourof an object (interface functions), as they must do

if the data are private, and the interface is designed with care, then we have a very robust design.The development of the class is totally decoupled from the development of the code that uses the

class. Hence, the internals of the class may be changed at will -- only the class and the classprogrammers will be affected.

2.11.4.0.1 Example

: The year2000 problem. The year2000 problem was cause not just by programmers using aninappropriate two-digit representation of year, but by all users of that representation having

access to the data. See above, coupling via data -- Figure 2.5.

2.11.5 Inheritance

Inheritance allows a derivedtype (class) to be defined as an extension, or specialisation of a base

type; i.e. derivedobjects inherit all the features ofbase, and add their own specialisations.

Inheritance allows us to build complex types/classes by reference to simpler classes. This

extension to a simple type is achieved by adding extra data fields, and adding operations orreplacing existing ones. However, since we do this by referring to the simpler class, rather than

by altering it, the integrity of the simpler type is unaffected.

There are at least two objections to the extension of existing software modules by alteration,reuse by duplication:

y It creates duplicated copies which must be separately maintained;y Altered software, however small the alteration, demands the full treatment of testing,

documentation, etc.


18/20

Suppose an application program deals withpeople - there are various categories of Person:Customers, Employees, Directors, etc. Inheritance allows a (derived/extended) class, e.g.

Employee, to be defined in terms of the (base) Person class. Moreover, with overloadingofinterface functions, client programs can treat objects of the two classes in a uniform way.

2.11.6 Multiple Interfaces

There are cases where an object may wish to offer different behaviours in different situations.

Thus in the course example, StudentInfo might offer an typically student-information interface:

take-marks; return average marks; return honours-pass-fail grade, etc. However, in addition, in a

sort routine which produces a ranking list, it may wish also to behave as a Comparable(number) object.

Java handles this situation by allowing a class to implement multiple interfaces. In C++ we usemultiple inheritance to provide multiple behaviours.

2.11.7 Late Binding

Late binding of functions allows client programs to take advantage of extended classes withoutalteration of the client code.

Note: Late binding is synonymous with dynamic bindingand run-time binding. This contrasts

with early binding--static binding, compile-time binding-- in which a function call is bound toa definite function at compile time. Late binding becomes operable when the type of a reference(variable) may change during the execution of a program -- according to the type of the last

value assigned to it.

Inheritance, with overloaded interface functions, will allow client programs to treat all classes inthe inheritancefamily in a uniform way -polymorphism. However, withplain inheritance, all

objects will be statically bound to a single class and, thereby, to interface functions of that class.

Inheritance, together with late binding permits the following:

Old code can call new code!.

Read that again! Old code can call new code. Normally, with libraries, new code, which must be

upper-level functions, is the callerand the calledcode -- the library functions is the oldcode.

But how does old code know about the new code? When maybe the new code didn't exist whenthe old code was written.

With dynamic binding, when an overloaded operation is invoked, the language takes care ofchoosing the appropriate version -- at run-time; thus, run-time binding. Hence, new code can be

bound to apolymorphic object at run time. Hence, systems can be extended without knock-on


19/20

requirements for reworking of the older parts of the system. This is the same as the upside-downlibrary effect mentioned above.

Here we find another form ofpolymorphism: objects may exhibit a sort-of dynamic typing, in

which and object takes the type of the last object assigned to it.

These notions are subtle - but should become clear with exposure to examples.

2.11.8 Open-closedModules

(Meyer, 1997)

For a module to be usable by a client - whether outside the organisation it was be closedtochanges of behaviour. Nevertheless, it must be open to possible extension. This remarkable

property, open-closed, is facilitated by inheritance and run-time binding.

2.11.9 Design-by-Contract

Meyer, (Meyer, 1997), see also (Mitchell & McKim, 2002), suggests a form of contract as the

only proper basis for design of modules (classes).

Thesupplierof the module agrees with the client:

1. What services the module should provide. These can be expressed aspost-conditions.2. Exclusions -- what the module is not expected to cope with. These exclusions can be

expressed aspre-conditions.

It takes little imagination, or experience of software development, or of life, to see the good

sense in design-by-contract.

Responsibility-driven-design, (Budd, 1999b) is a similar concept.

2.12 Summary

y Complexity of large software projects -programming in the large.y Software crisis.y

Quality.y Productivity.y Design forchange and reuse.y OOP languages.y OOPparadigm.y Goals of software engineering.y Summary of waterfall life-cycle and structured systems analysis and design.y Limitations of waterfall life-cycle and structured systems analysis and design.


20/20

y Object-oriented model/architecture.y Event driven interaction.y Cornerstones of modern software engineering and object-oriented programming.

Next:3. Classes and ObjectsUp:Lecture Notes on Object-orientedPrevious:1. Introduction

and Overview

171 7

Itroduction to Object Oriented Programming

Documents

Transcript of Itroduction to Object Oriented Programming