Chapter One The Object-Oriented Paradigm

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

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 The Object-Oriented Paradigm

Overview • Object-Oriented Paradigm • Compare and contrast withStandard Structured Programming • Contents • Functional decomposition • Problem of requirements • Object-oriented paradigm • Special object methods • Important object terminology The 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 • Display shapes The Object-Oriented Paradigm

Functional Decomposition • It would be natural to think in terms of the steps required: • Locate the list of shapes in the database. • Open up the list of shapes. • Sort the list according to some rules. • Display the individual shapes on the monitor. The Object-Oriented Paradigm

Functional Decomposition • Further break down Step 4. • Locate the list of shapes in the database. • Open up the list of shapes. • Sort the list according to some rules. • Display the individual shapes on the monitor. • Identify type of shape. • Get location of shape. • Call appropriate function that will display shape, giving it the shape’s location. The Object-Oriented Paradigm

Functional Decomposition • A natural way to deal with complexity • 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 • Dealing with change – a graceful evolution The Object-Oriented Paradigm

Functional Decomposition • Many bugs originate with changes to code. • 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. • Too much is unknown about the future – things change. The Object-Oriented Paradigm

The Problem of Requirements • Requirements from users are • Incomplete • Usually wrong • Misleading • Do not tell the whole story • Requirements always change. • A bad thing • Few write their code to handle changing requirement The 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. • Developers become more familiar with users’ problem domain. • The environment in which the software is being developed changes. • Must write our code to accommodate change • Not give up on gathering good requirements The Object-Oriented Paradigm

Dealing with Changes:Using Functional Decomposition • Using modularity to contain variation • Make code more modular • Step 4c of displaying shapes • 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 circle: put display function for circle here The 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 • Understandability • Make the code easier to maintain • Does not deal with all of the variation it might encounter The Object-Oriented Paradigm

Low Cohesion and Tight Coupling • Cohesion • How closely the operations in a routine are related • Coupling • The strength of a connection between two routines • Goal • To create routines with internal integrity (strong cohesion) and small, direct, visible, and flexible relations to other routines (loose coupling) The 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 • 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 • Finding bugs • Avoiding unwanted side effects The 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 • Like a snowball that picks up snow as it rolls downhill The Object-Oriented Paradigm

Dealing withChanging Requirements • How do people do thing? • Example • 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. • Structured programming approach • Get list of people in the class. • For each person on this list: • Find the next class they are taking • Find the location of that class • Find the way to get from your classroom to the person’s next class • Tell the person how to get to their next class The Object-Oriented Paradigm

Dealing withChanging Requirements • Require following procedures • A way of getting the list of people in the class • A way of getting the schedule for each person in the class • A program that gives someone directions from your classroom to any other classroom • 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 • Expect everyone would know what their next class was The Object-Oriented Paradigm

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

The Impact • New requirements • 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 The Object-Oriented Paradigm

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

What Makes It Happen • The people are responsible for themselves • 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 The Object-Oriented Paradigm

Perspectives in the Software Development Process • Conceptual • The concepts in the domain under study • With little or no regard for the software that might implement it • Specification • Look at the interface of the software, not implementation • Implementation • Look at the code itself The Object-Oriented Paradigm

How Perspectives Help • Conceptual level • Go to your next class • What to do, not how to do • Implementation level • 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 • Only know conceptually what is happening The Object-Oriented Paradigm

The Object-Oriented Paradigm • Centered on the concept of the object • Object • 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 • Data: to know what state it is in • Method (Code): to function properly The Object-Oriented Paradigm

Objects and Their Responsibilities The Object-Oriented Paradigm

How to Think About Objects • Objects • Something with responsibilities • A good design rule • Objects should be responsible for themselves and should have those responsibilities clearly defined The Object-Oriented Paradigm

How to Think About Objects • At the conceptual level • 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 • At the implementation level • An object is code and data The 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() • 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 • Be used or tailored to their needs The Object-Oriented Paradigm

The 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 methods the object can do • The way these data elements and methods can be accessed • Objects are instances of classes • Creating instances of a class is called instantiation • Each object of the same type • Different data, but have the same functionality The Object-Oriented Paradigm

Go to the Next Classroom • Start the control program • Instantiate the collection of students in the classroom • Tell the collection to have the students go to their next class • The collection tells each students to go to their next class • Each student • Finds where his next class is • Determines how to get there • Goes there • Done The Object-Oriented Paradigm

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

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

Abstract Class • Inheritance • An is-a relationship • RegularStudent class inherits from Student • Derives from • Specializes • A subclass of • Student class is the base class of GraduateStudent and of RegularStudent • Generalizes • A superclass of The Object-Oriented Paradigm

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

Visibility • Public • Anything can see it • Protected • Only objects of this class and derived classes can see it • Private • Only objects from this class can see it The Object-Oriented Paradigm

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

Review of OO Terminology • Object • Class • Encapsulation • Inheritance • Instance • Instantiation • Polymorphism • Perspectives The Object-Oriented Paradigm

New Example • Shape Example • Locate the list of shapes in the database • Open up the list of shapes • Sort the list according to some rules • Display the individual shapes on the monitor The Object-Oriented Paradigm

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

Objects in Shape Program • Collection • display – tell all contained shapes to display • sort – sort the collection of shapes • Display • drawLine – draw a line on the screen • drawCircle – draw a circle on the screen The 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 • 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 The Object-Oriented Paradigm

New Requirements • Add new kinds of shapes (such as a triangle) • Create a new derivation of Shape that defines the shape. • 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 The Object-Oriented Paradigm

Encapsulation Revisited • Using things is easier • 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 The 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 The Object-Oriented Paradigm

Chapter One The Object-Oriented Paradigm