1. Chapter One The Object-Oriented Paradigm Ku-Yaw Chang canseco@mail.dyu.edu.tw Assistant Professor, Department of Computer Science and Information Engineering Da-Yeh University

2. 2Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

3. 3Ku-Yaw ChangThe Object-Oriented Paradigm Overview Object-Oriented Paradigm Compare and contrast with Standard Structured Programming Compare and contrast with Standard Structured ProgrammingContents Functional decomposition Functional decomposition Problem of requirements Problem of requirements Object-oriented paradigm Object-oriented paradigm Special object methods Special object methods Important object terminology Important object terminology

4. 4Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

5. 5Ku-Yaw ChangThe Object-Oriented Paradigm Functional Decomposition A natural way to deal with complexity Example: You are given a task to write code to Access a description of shapes that were stored in a database Access a description of shapes that were stored in a database Display shapes Display shapes

6. 6Ku-Yaw ChangThe Object-Oriented Paradigm Functional Decomposition It would be natural to think in terms of the steps required: 1. Locate the list of shapes in the database. 2. Open up the list of shapes. 3. Sort the list according to some rules. 4. Display the individual shapes on the monitor.

7. 7Ku-Yaw ChangThe Object-Oriented Paradigm Functional Decomposition Further break down Step 4. 1. Locate the list of shapes in the database. 2. Open up the list of shapes. 3. Sort the list according to some rules. 4. Display the individual shapes on the monitor. a) Identify type of shape. b) Get location of shape. c) Call appropriate function that will display shape, giving it the shape’s location.

8. 8Ku-Yaw ChangThe Object-Oriented Paradigm Functional Decomposition A natural way to deal with complexity Break down (decompose) the problem into the functional steps that compose it. Break down (decompose) the problem into the functional steps that compose it.Challenge Not help us prepare the code for possible changes in the future Not help us prepare the code for possible changes in the future Dealing with change – a graceful evolution

9. 9Ku-Yaw ChangThe Object-Oriented Paradigm Functional Decomposition Many bugs originate with changes to code. Change creates opportunities for mistakes and unintended consequences. Change creates opportunities for mistakes and unintended consequences. Nothing you can do will stop change. But you do not have to be overcome by it. You can never get all of requirements from the user. You can never get all of requirements from the user. Too much is unknown about the future – things change. Too much is unknown about the future – things change.

10. 10Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

11. 11Ku-Yaw ChangThe Object-Oriented Paradigm The Problem of Requirements Requirements from users are Incomplete Incomplete Usually wrong Usually wrong Misleading Misleading Do not tell the whole story Do not tell the whole story Requirements always change. A bad thing A bad thing Few write their code to handle changing requirement Few write their code to handle changing requirement

12. 12Ku-Yaw ChangThe Object-Oriented Paradigm The Problem of Requirements Requirements change for a very simple set of reasons: The users see new possibilities for the software after discussions with developers. The users see new possibilities for the software after discussions with developers. Developers become more familiar with users’ problem domain. Developers become more familiar with users’ problem domain. The environment in which the software is being developed changes. The environment in which the software is being developed changes. Must write our code to accommodate change Not give up on gathering good requirements Not give up on gathering good requirements

13. 13Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

14. 14Ku-Yaw ChangThe Object-Oriented Paradigm Dealing with Changes: Using Functional Decomposition Using modularity to contain variation Make code more modular Make code more modular Step 4c of displaying shapes Call appropriate function that will display shape, giving it the shape’s location Call appropriate function that will display shape, giving it the shape’s location function : display shape input: type of shape, description of shape action: switch (type of shape) case square: put display function for square here case square: put display function for square here case circle: case circle: put display function for circle here

15. 15Ku-Yaw ChangThe Object-Oriented Paradigm Problems with Modularity May or may not be possible to have a consistent description of shapes that will work for all shapes Modularity Make the code more understandable Make the code more understandable Understandability Understandability Make the code easier to maintain Does not deal with all of the variation it might encounter Does not deal with all of the variation it might encounter

16. 16Ku-Yaw ChangThe Object-Oriented Paradigm Low Cohesion and Tight Coupling Cohesion How closely the operations in a routine are related How closely the operations in a routine are relatedCoupling The strength of a connection between two routines The strength of a connection between two routinesGoal To create routines with internal integrity (strong cohesion) and small, direct, visible, and flexible relations to other routines (loose coupling) To create routines with internal integrity (strong cohesion) and small, direct, visible, and flexible relations to other routines (loose coupling)

17. 17Ku-Yaw ChangThe Object-Oriented Paradigm Unwanted Side Effect Unwanted side effect Make a change to a function or piece of data in one area of the code Make a change to a function or piece of data in one area of the code Have an unexpected impact on other pieces of code We really do not spend much time fixing bugs. The overwhelming amount of time spent in maintenance and debugging is on The overwhelming amount of time spent in maintenance and debugging is on Finding bugs Avoiding unwanted side effects

18. 18Ku-Yaw ChangThe Object-Oriented Paradigm Wrong Focus Changes to one set of functions or data impact other sets of functions and other sets of data In turn impact other functions that must be changed In turn impact other functions that must be changed Like a snowball that picks up snow as it rolls downhill

19. 19Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

20. 20Ku-Yaw ChangThe Object-Oriented Paradigm Dealing with Changing Requirements How do people do thing? Example You were an instructor at a conference You were an instructor at a conference People in your class had another class to attend following yours, but didn’t know where it was located. People in your class had another class to attend following yours, but didn’t know where it was located. Structured programming approach 1. Get list of people in the class. 2. For each person on this list: a.Find the next class they are taking b.Find the location of that class c.Find the way to get from your classroom to the person’s next class d.Tell the person how to get to their next class

21. 21Ku-Yaw ChangThe Object-Oriented Paradigm Dealing with Changing Requirements Require following procedures 1. A way of getting the list of people in the class 2. A way of getting the schedule for each person in the class 3. A program that gives someone directions from your classroom to any other classroom 4. A control program that works for each person in the class and does the required steps for each person Would you actually follow this approach? Post directions in the back of the room Post directions in the back of the room Expect everyone would know what their next class was Expect everyone would know what their next class was

22. 22Ku-Yaw ChangThe Object-Oriented Paradigm Difference First case Give explicit directions to everyone. Give explicit directions to everyone. No one other than you is responsible for anything. No one other than you is responsible for anything. Second case Give general instructions Give general instructions Each person figure out how to do the task himself or herself Each person figure out how to do the task himself or herself Shift of responsibility The same thing must be implemented. The same thing must be implemented. The organization is very different. The organization is very different.

23. 23Ku-Yaw ChangThe Object-Oriented Paradigm The Impact New requirements Give special instructions to graduate students who are assisting at the conference Give special instructions to graduate students who are assisting at the conference Collect course evaluations Take them to the conference office before going to the next class

24. 24Ku-Yaw ChangThe Object-Oriented Paradigm Why the Difference First case Modify the control program to distinguish the graduate students from the undergraduates Modify the control program to distinguish the graduate students from the undergraduates Give special instructions to the graduate students Give special instructions to the graduate students Modify the program considerably Second case Write an additional routine for graduate students to follow Write an additional routine for graduate students to follow Control program remains the same Control program remains the same Significant difference Control program Control program

25. 25Ku-Yaw ChangThe Object-Oriented Paradigm What Makes It Happen The people are responsible for themselves Instead of the control program being responsible for them Instead of the control program being responsible for them The control program can talk to different types of people as if they were exactly the same The control program does not need to know about any special steps

26. 26Ku-Yaw ChangThe Object-Oriented Paradigm Perspectives in the Software Development Process Conceptual The concepts in the domain under study The concepts in the domain under study With little or no regard for the software that might implement it With little or no regard for the software that might implement itSpecification Look at the interface of the software, not implementation Look at the interface of the software, not implementationImplementation Look at the code itself Look at the code itself

27. 27Ku-Yaw ChangThe Object-Oriented Paradigm How Perspectives Help Conceptual level Go to your next class Go to your next class What to do, not how to do What to do, not how to do Implementation level The way they go to their class The way they go to their class Communicating at one level (conceptually) while performing at another level (implementation) The requestor (the instructor) does not know exactly what is happening The requestor (the instructor) does not know exactly what is happening Only know conceptually what is happening

28. 28Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

29. 29Ku-Yaw ChangThe Object-Oriented Paradigm Centered on the concept of the object Object Data with methods Data with methods Data (Attributes) can be simple things like number or character strings, or they can be other objects Define things that are responsible for themselves Define things that are responsible for themselves Data: to know what state it is in Method (Code): to function properly

30. 30Ku-Yaw ChangThe Object-Oriented Paradigm Objects and Their Responsibilities This Object… Is Responsible For Student Knowing which classroom they are in Know which classroom they are to go to next Going from one classroom to the next classroom Instructor Telling people to go to next classroom Classroom Having a location Direction Giver Given two classrooms, giving directions from one classroom to the other

31. 31Ku-Yaw ChangThe Object-Oriented Paradigm How to Think About Objects Objects Something with responsibilities Something with responsibilities A good design rule Objects should be responsible for themselves and should have those responsibilities clearly defined Objects should be responsible for themselves and should have those responsibilities clearly defined

32. 32Ku-Yaw ChangThe Object-Oriented Paradigm How to Think About Objects At the conceptual level An object is a set of responsibilities An object is a set of responsibilities At the specification level An object is a set of methods that can be invoked by other objects or by itself An object is a set of methods that can be invoked by other objects or by itself At the implementation level An object is code and data An object is code and data

33. 33Ku-Yaw ChangThe Object-Oriented Paradigm Public Interface Many methods of an object will be identified as callable by other objects. The collection of these methods is called the object’s public interface Student object with the method gotoNextClassroom() Student object with the method gotoNextClassroom() More kinds of students More kinds of students Inefficient for each student type to have its own set of methods A more efficient approach A general student to contain common methods A general student to contain common methods Be used or tailored to their needs Be used or tailored to their needs

34. 34Ku-Yaw ChangThe Object-Oriented Paradigm A class is a definition of the behavior of an object, containing a complete description of The data elements the object contains The data elements the object contains The methods the object can do The methods the object can do The way these data elements and methods can be accessed The way these data elements and methods can be accessed Objects are instances of classes Creating instances of a class is called instantiation Creating instances of a class is called instantiation Each object of the same type Each object of the same type Different data, but have the same functionality

35. 35Ku-Yaw ChangThe Object-Oriented Paradigm Go to the Next Classroom 1.Start the control program 2.Instantiate the collection of students in the classroom 3.Tell the collection to have the students go to their next class 4.The collection tells each students to go to their next class 5.Each student Finds where his next class is Finds where his next class is Determines how to get there Determines how to get there Goes there Goes there 6.Done

36. 36Ku-Yaw ChangThe Object-Oriented Paradigm The Need for an Abstract Type The dilemma Allow any type of student into the collection Allow any type of student into the collection The collection is an array or something of some type of object The collection is an array or something of some type of objectRegularStudentGraduateStudent The solution A general type that encompasses more than one specific type A general type that encompasses more than one specific type Student : an abstract class RegularStudent RegularStudent GraduateStudent GraduateStudent

37. 37Ku-Yaw ChangThe Object-Oriented Paradigm Abstract Class Abstract class define what other, related classes can do. These “other” classes represent a particular type of related behavior. These “other” classes represent a particular type of related behavior. Such a class is often called a concrete class. Such a class is often called a concrete class. The abstract class is Student Concrete classes are RegularStudent and GraduateStudent Concrete classes are RegularStudent and GraduateStudent RegularStudent is one kind of Student GraduateStudent is one kind of Student

38. 38Ku-Yaw ChangThe Object-Oriented Paradigm Abstract Class Inheritance An is-a relationship An is-a relationship RegularStudent class inherits from Student Derives from Derives from Specializes Specializes A subclass of A subclass of Student class is the base class of GraduateStudent and of RegularStudent Generalizes Generalizes A superclass of A superclass of

39. 39Ku-Yaw ChangThe Object-Oriented Paradigm Abstract Class Placeholders for other classes Define the methods their derived classes must implement Define the methods their derived classes must implement Contain common methods that can be used by all derivations Contain common methods that can be used by all derivations Controller contains Students The collection only needs to deal with Students The collection only needs to deal with Students Each kind of Student is left to implement its functionality in its own way Each kind of Student is left to implement its functionality in its own way

40. 40Ku-Yaw ChangThe Object-Oriented Paradigm Visibility Public Anything can see it Anything can see itProtected Only objects of this class and derived classes can see it Only objects of this class and derived classes can see itPrivate Only objects from this class can see it Only objects from this class can see it

41. 41Ku-Yaw ChangThe Object-Oriented Paradigm Encapsulation and Polymorphism Encapsulation Hiding data Hiding data In general, any kind of hiding Polymorphism Poly : many Poly : many Morph : form Morph : form Different behavior Different behavior Depend upon the specific type of derived object

42. 42Ku-Yaw ChangThe Object-Oriented Paradigm Review of OO Terminology ObjectClassEncapsulationInheritanceInstanceInstantiationPolymorphismPerspectives

43. 43Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

44. 44Ku-Yaw ChangThe Object-Oriented Paradigm New Example Shape Example 1. Locate the list of shapes in the database 2. Open up the list of shapes 3. Sort the list according to some rules 4. Display the individual shapes on the monitor

45. 45Ku-Yaw ChangThe Object-Oriented Paradigm Objects in Shape Program ShapeDataBase getCollection – get a specified collection of shapes getCollection – get a specified collection of shapes Shape (an abstract class) display – defines interface for Shapes display – defines interface for Shapes getX – return X location of Shape getX – return X location of Shape getY – return Y location of Shape getY – return Y location of Shape Square (derived from Shape) display – display a square (represented by this object) display – display a square (represented by this object) Circle (derived from Shape) Display – display a circle (represented by this object) Display – display a circle (represented by this object)

46. 46Ku-Yaw ChangThe Object-Oriented Paradigm Objects in Shape Program Collection display – tell all contained shapes to display display – tell all contained shapes to display sort – sort the collection of shapes sort – sort the collection of shapesDisplay drawLine – draw a line on the screen drawLine – draw a line on the screen drawCircle – draw a circle on the screen drawCircle – draw a circle on the screen

47. 47Ku-Yaw ChangThe Object-Oriented Paradigm Main Program Create an instance of the database object Ask the database object to find the set of shapes Instantiate a collection object containing all of the shapes Instantiate a collection object containing all of the shapes Ask the collection to sort the shapes Ask the collection to display the shapes The collection asks each shape to display itself Each shape display itself

48. 48Ku-Yaw ChangThe Object-Oriented Paradigm New Requirements Add new kinds of shapes (such as a triangle) Create a new derivation of Shape that defines the shape. Create a new derivation of Shape that defines the shape. Implement a version of the display method that is appropriate for that type Implement a version of the display method that is appropriate for that type Change the sorting algorithm Modify the method in Collection. Every shape will use the new algorithm Modify the method in Collection. Every shape will use the new algorithm

49. 49Ku-Yaw ChangThe Object-Oriented Paradigm Encapsulation Revisited Using things is easier User does not need to worry about implementation issues User does not need to worry about implementation issues Implementations can be changed without worrying about the caller The insides of an object are unknown to outside objects

50. 50Ku-Yaw ChangThe Object-Oriented Paradigm Benefits The more I make my objects responsible for their own behaviors, the less the controlling programs have to be responsible for. Encapsulation makes changes to an object’s internal behavior transparent to other objects. Encapsulation helps to prevent unwanted side effects

51. 51Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

52. 52Ku-Yaw ChangThe Object-Oriented Paradigm Special Object Methods Constructor A special method that is automatically called when the object is created A special method that is automatically called when the object is created Handle starting up the object Handle starting up the object To eliminate uninitialized variables Destructor A special method that helps an object clean up after itself when the object is destroyed A special method that helps an object clean up after itself when the object is destroyed Release resources Release resources Java Java Garbage collection

53. 53Ku-Yaw ChangThe Object-Oriented Paradigm Outline Overview Before the Object-Oriented Paradigm: Functional Decomposition The Problem of Requirements Dealing with Changes: Using Functional Decomposition Dealing with Changing Requirements The Object-Oriented Paradigm Object-Oriented Programming in Action Special Object Methods Summary

54. 54Ku-Yaw ChangThe Object-Oriented Paradigm Summary Object orientation helps us minimize consequences of shifting requirements In contrast with functional decomposition In contrast with functional decomposition Essential concepts and primary terminology in object-oriented programming

55. The End