MODULE 11 OBJECTORIENTED PROGRAMMING Objectives Introduce OOP programming

MODULE 11 – OBJECT-ORIENTED PROGRAMMING : Objectives - Introduce O-OP programming paradigm - to describe the general characteristics of objectoriented paradigm/approach - to describe some key terms of O-OP - to outline some practical problems associated with using O-OP Mr. Joseph Ecklu (DCS) Slide 1

Reading List • Object-Oriented Programming with C++ by David Parson, pages 1 to 12

O-OP • - TOPICS Recap of IMPERATIVE programming ‘Object-Orientation’ Object and Object classification Decomposition ( Functional and Data ) Modularity Basic terminology and Ideas O-O Programming Problems associated with O-O Mr. Joseph Ecklu (DCS) Slide 3

O-OP • RECAP OF IMPERATIVE programming Principle imperative paradigm is the fully controlled manipulation of named data in a step-wise fashion Specify the named data and the manipulations, and to control the stepping ‘do this, then do that’ structure Separates data from processes Mr. Joseph Ecklu (DCS) Slide 4

O-OP -data declaration Specifying the named data is done through data declaration e. g. int big; float biga; char lett; -data manipulation Data manipulation is done through state-changing commands e. g. biga = big + 66; -control the stepping Controlling the stepping is called flow of control e. g for( keyj = 1; keyj < 10; keyj++) Mr. Joseph Ecklu (DCS) Slide 5

O-OP • Popular imperative Languages – C, C++, FORTRAN, PASCAL – example of imeprative program using C++ lang. • • Mr. Joseph Ecklu (DCS) #include <iostream> using namesapce std; int main() { int big; for (big = 1; big <10; big++) { cout << “Number : “ << big << endl; } return 0; } Slide 6

O-OP • Object Orientation Is about trying to represent the ‘objects’ that we find in the real world in software. Mr. Joseph Ecklu (DCS) Slide 7

• Types of objects we can find in real life (according to Shlaer and Mellor , 1988) 1. Tangible Things : Physical objects, e. g. school, tree, bus 2. Roles : Of people or organisations e. g. ‘account holder’ , ‘employer’, ‘driver’ 3. Incidents : something happening at a particular time e. g. ‘transaction’ , ‘flight’, ‘trip’ 4. Interactions : a link between objects e. g. ‘contracts’, ‘electrical connection’ 5. Specifications : a definition of a set of other objects e. g. A description of a particular type of stock item Mr. Joseph Ecklu (DCS) Slide 8

• Physical Objects Generally, objects are the elements through which we perceive the world around us, ‘things’ that have recognizable identities and particular behaviours Mr. Joseph Ecklu (DCS) Slide 9

O-OP • Major characteristics of Physical objects – Identity = what we call an object – Behaviour = what an object does, which enable us to recognise them as discrete things – Exhibit ‘State’ = we can describe what an object is as well as what it does and what it is called Mr. Joseph Ecklu (DCS) Slide 10

• Physical Objects can be classified/class Key element in the object-orientation model is that objects can be classified into types Individual objects can be classified according to their common characteristics e. g. that all cats are of a single type, although we can identify individual differences between specific cats, our perception is that all individual cats belong to a general ‘class’ which we call Cat Class = objects that have common characteristics We ‘know about’ all cats because we recognise what they have in common Mr. Joseph Ecklu (DCS) Slide 11

• Physical Objects that contain other objects some objects are composed of other objects example A ‘house’ object’ is composed of other objects such as bricks, window, doors, tiles etc. Mr. Joseph Ecklu (DCS) Slide 12

• Objects in software/Programs the basic philosophy of using objects in programs is : the world is composed of interacting classifiable identifiable objects and therefore programs too can usefully be structured in this way Mr. Joseph Ecklu (DCS) Slide 13

O-OP Since all software applications serve people living in the real world, then that software should mirror the real world as closely as possible, both in its workings and in its underlying design Mr. Joseph Ecklu (DCS) Slide 14

O-OP • Object = (private) Data + (public) Processes Object-oriented approach unifies inside objects data and processes Mr. Joseph Ecklu (DCS) Slide 15

O-OP • Encapsulation the linking of these two aspects of programming-data and processes, is known as ‘encapsulation’ and allows the implementation of ‘information hiding’ (restricted access to the internal representation of objects) Mr. Joseph Ecklu (DCS) Slide 16

O-OP • Private and Public parts of objects have a ‘private’ part of hidden internal detail (state data and internal processes) and a ‘public’ interface which clearly defines the set of possible behaviours of the object (the messages to which it can respond) Mr. Joseph Ecklu (DCS) Slide 17

• Private and Public in the Programming process This separation of the public interface of an object and its private/internal implementation allows the programmer to treat the two as separate parts of the programming process Mr. Joseph Ecklu (DCS) Slide 18

• Private part of object i. e. an object’s private implementation details can be defined without reference to other objects or a particular application context, and then The object may be used in an application that utilises only the object’s public interface Mr. Joseph Ecklu (DCS) Slide 19

• Abstract Data Type (ADT) both the public and private part of an object are defined in an abstract data type which defines the common aspects of all objects in a particular ‘class’ i. e. objects that we classify as one type Mr. Joseph Ecklu (DCS) Slide 20

• Decomposition : complexity reduction Partitioning of large programming projects, before the coming of object-orientation, are done using the structured methods of - Process Driven ( functional decomposition) - Data Driven (Data decomposition ) Mr. Joseph Ecklu (DCS) Slide 21

• Process Driven ( functional decomposition) also called algorithmic decomposition • the programming process is decomposed into constituent processes, each of which should be coherent and simple module • the structure of the data which these modules process is a secondary consideration = data tends to be generally spread across a system with little organisation Mr. Joseph Ecklu (DCS) Slide 22

• Data driven (data decomposition ) Sets of data are used to design the program, so that the internal structures of data are used to organise the processes that take place Large amounts of data being processed in a way dictated by an arbitrary file or database structure that may be used in many different applications Mr. Joseph Ecklu (DCS) Slide 23

• Problem Both approaches are Computer-oriented paradigms Process driven is based on the organisation of computer processes Data driven is based on of data files Mr. Joseph Ecklu (DCS) Slide 24

MODULARITY • Object-Orientation Provides true modularity in which software modules (objects) provide the ultimate in: 1. Low (data) Coupling 2. High (functional) Cohesion Mr. Joseph Ecklu (DCS) Slide 25

• 1. Low ( data ) Coupling the extent to which different modules / objects rely on one another and/or external data in order to function Objects/modules must exhibit low coupling implies they are not tied to a particular environment in order to function Mr. Joseph Ecklu (DCS) Slide 26

External Interface Is clearly defined in terms of the operations that the object can undergo and any external inputs that affect the object’s behaviour Mr. Joseph Ecklu (DCS) Slide 27

• ‘message passing’ An object’s coupling to other objects is through flexible ‘message passing’ mechanisms. Objects message passing mechanism tend to vary widely between applications Allows an object to be easily decoupled from a particular application and coupled to another Mr. Joseph Ecklu (DCS) Slide 28

• 2. High ( functional ) Cohesion the extent to which a programming module makes sense as an entity A ‘highly cohesive object’ is one that has a clearly defined role Mr. Joseph Ecklu (DCS) Slide 29

• Functional cohesion object This is an ideal functional decomposition which results in a module/object that performs one problem-oriented task Real world objects Object-orientation can go beyond functional cohesion and encapsulate together functions related to data representations of real world objects Eg. Car , tree, cat Computational objects e. g. stacks, queues, lists exhibit the same characteristics of modularity just as real world objects Mr. Joseph Ecklu (DCS) Slide 30

• Benefits of modularity/ object-orientation 1. Reusability 2. Extensibility Mr. Joseph Ecklu (DCS) Slide 31

Session Summary Object-Oriented Programs ties to represent the ‘objects’ that we find in the real world in software. This session took a look at objects in the context of interacting classifiable identifiable and how it can be used in the field of C++ programming