Introduction to Classes and Objects Real Life

Introduction to Classes and Objects

Real Life • When a design engineer needs an electrical motor he doesn’t need to worry about – How a foundry will cast the motor housing – How the copper wire will be refined and manufactured – How the motor is constructed • He will simply be concerned with selecting – – The right mounting The correct power requirements The correct rotational speed and horsepower Providing adequate ventilation • If he meets the specifications then so will the motor. • It’s like a contract

The Scenario • We want to provide this same sort of a “black box” approach to reusable components… Input Don’t know how it works, but it works! Output

The Scenario • We want to create reusable components for other programmers to use. • They are focused on their work and don’t want to know the details of how our component works. • They are also busy trying to do their work, so maybe they’ll take shortcuts and “hack. ” • We want to provide services to them but protect the implementation details of our components.

Classes • A class is the fundamental unit of object-oriented programming. • It allows us to implement ADTs, combining both data and operations into one logical bundle.

Objects • Once we have a class defined, we can then declare any number of objects of that class. For example: • Once we have a queue class defined, we can then declare any number of queue objects. • Each queue object will then have all the data and procedural abstractions needed for a queue.

Classes and Objects • A class is like a blueprint or specification: • An object is an instantiated class (like a building):

One to Many • Once we have the class which is like a blueprint or spec. . . • We may produce one item – Like the College of Computing Building – Like Turner Field • We may produce many copies – Like 1 HP 3600 RPM Electrical Motors – Like F-22 Fighters – Like golf balls • The choice simply depends on the given application

Classes vs. Objects • Class refers to the template by which we implement the functionality of an ADT. Thus, it is analogous to data type: it is only a definition or template. • Object refers to a specific instance of the class. Thus, it is analogous to variable: it is an instance of a template. Class : Object : : Type : Variable

Classes Allow for Reuse! • Algorithms which make use of the queue class (by declaring instances of the queue, or objects) are clients who obtain services: Restaurant Check-out line Printer queue Automated distribution center • The authors of these algorithms can instantiate and use queues without writing them!

Components of a Class • The individual data elements of a class are referred to as attributes or fields of the class. • The values of the entire collection of data items maintained within an object is referred to as the state of the object. • The operations (procedures and functions) that are provided by the class (and thus allowed on the data) are called the methods of the class or object.

Controlling Visibility • Recall we want to protect the implementation of the class. – Users shouldn’t need to know how it works – Users shouldn’t be able to violate the behaviors (may only do what we allow them). • Encapsulation allows us to hide the implementation details.

Visibility Within a Class The rest of the world Public Section (Interface) Private Section (Implementation)

Anatomy of a Class For now, consider class components to have two types: • Public - components which are "visible” to clients • Private - components which are "hidden” from clients

Public Parts • Everything that the client algorithm needs to know to use the class • The visible parts of the class • Defines the interface and contract with the user.

Private Parts • Contains the details of the implementation of the class • Cannot be seen by the client algorithm • Hide attributes and method implementation

Interactions Client Algorithm Public Methods and Contract Server Object Private Data & Methods

Encapsulation and Hiding • A client algorithm can see only the public parts of the class. A client has no idea what the private parts contain. • A client algorithm can interact with an object only by calling the methods listed as public. • A client algorithm cannot directly access any of the private data or methods within an object. It may “get at” these only via calls to public methods.

Public vs. Private Methods public method 1 Some Class class data public method 2 public method 3 a private method • Clients may call any/all of the three public methods. • Clients don’t know the private method exists; they cannot call it. • Private methods will be called by other public methods

Documentation

Design by Contract • An essential ingredient of good Object Oriented programming is known as design by contract. • This means that before modules are written a specification or contract is written which states • What preconditions must be met for the module to properly function • What is the purpose of the module • What will be the state of things after the module executes which is known as the postconditions

Example • A module located in a Queue class which will dequeue the element at the head of the queue. // Precondition -- The queue must be instantiated. It is recommended that is. Empty be run to assure that their is an element to dequeue // Purpose -- Remove the element at the head of the queue and return it to the user. It will be an Object. // Postcondition -- The queue will have one fewer element unless the queue was empty to start with in which case the method will return null and the queue will be unchanged

Recall • Simple Linked List Record LLNode definesa record data isoftype Num Next isoftype Ptr toa Node Endrecord // LLNode • Now with object oriented programming we wish to create Linked List Node objects • They will contain data similar to above • Plus methods that can act on that data

A Simple Class class LLNode { private int data; private LLNode next; // Precon: instantiation // Purpose: sets data field // Postcon: data field will be set public void set. Data(int i) { // modifier data = i; } // Precon: data filed should be initialized // Purpose: returns contents of data field // Postcon: no change to object public int get. Data() { // accessor return data; }

A Simple Class // Precon: initialization // Purpose: sets value of next field // Postcon: value of next field will be changed public void set. Next(LLNode n) { // modifier next = n; } // Precon: next field has been initialized // Purpose: return value of next field // Postcon: no change to object public LLNode get. Next() { // accessor return next; } This may seem like a } // LLNode lot of busy work but it’s the general way of doing it!

Scope of Data Access • Recall in Pseudocode variables always had scope or visibility only within the module wherein they were declared • Constants and Definitions (Records and Arrays) were Global (i. e visible anywhere) • One of the necessities of our desire to hide or encapsulate details from the user of a class is that variables declared inside the class (not in a method) have Global Scope inside the class!!!

A Simple Class class LLNode { private int data; data private LLNode next; next public void set. Data(int i) { data = i; } public int get. Data() { return data; data } public void set. Next(LLNode n) { next = n; } public LLNode get. Next() { return next; next } } // LLNode // modifier // accessor