1 / 28

Introduction to Classes and Objects

Learn how objects are like blueprints in object-oriented programming, allowing for the creation of reusable components for efficient programming. Understand the concepts of classes, objects, encapsulation, visibility control, and the interactions between client algorithms and server objects.

jwoodford
Download Presentation

Introduction to Classes and Objects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Introduction to Classes and Objects

  2. 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

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

  4. 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.

  5. 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.

  6. 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.

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

  8. 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

  9. 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

  10. 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!

  11. 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 stateof the object. • The operations (procedures and functions) that are provided by the class (and thus allowed on the data) are called the methodsof the class or object.

  12. 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.

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

  14. 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 [A third type, Protected, will show up later]

  15. 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.

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

  17. Interactions Client Algorithm Public Methodsand Contract Server Object Private Data & Methods

  18. Encapsulation and Hiding • A client algorithm can see only the public parts of the class. Aclient 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.

  19. Public vs. Private Methods 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 Some Class publicmethod 1 publicmethod 3 class data publicmethod 2 a privatemethod

  20. Documentation

  21. 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

  22. 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 isEmpty 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

  23. 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

  24. 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 setData(int i) { // modifier data = i; } // Precon: data filed should be initialized // Purpose: returns contents of data field // Postcon: no change to object public int getData() { // accessor return data; }

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

  26. 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!!!

  27. A Simple Class class LLNode { private int data; private LLNode next; public void setData(int i) { // modifier data = i; } public int getData() { // accessor return data; } public void setNext(LLNode n) { // modifier next = n; } public LLNode getNext() { // accessor return next; } } // LLNode

More Related