Recap: Object Oriented Approach
 Four major elements:
 Abstraction
 Encapsulation
 Modularity
 Hierarchy
 Three minor elements:
 Typing
 Concurrency
 Persistence
Abstraction
Car
Jeep
Motor
Bike
LemonTruck
Apple
Banana
Mango
Chiku
Maruti
Wagon-R
Bajaj
Scooter
Abstraction
 Dahl, Dijkstra, and Hoare suggest that “abstraction
arises from a recognition of similarities
between certain objects, situations, or processes in
the real world, and the decision to concentrate
upon these similarities and to ignore for the time
being the differences” [42].
Abstraction
 An abstraction denotes the essential
characteristics of an object that distinguish it from
all other kinds of objects and thus provide crisply
defined conceptual boundaries, relative to the
perspective of the viewer.
Abstraction: Perspective of User
Parent
Child Name
Class
Roll No
Mobile No
Employee
Name
Id No
Mobile No
Tax Payer
Name
Pan No
Annual Return
Bank Customer
Name
Pan No
Acct No
Acct Type
Loyalty Program
Member
Name
Card No
Points
Abstraction
 An abstraction focuses on the outside view of an
object and so serves to separate an object’s
essential behavior from its implementation.
 Deciding on the right set of abstractions for a given
domain is the central problem in object-oriented
design.
Abstraction
 Abstraction or separation of behavior / implementation
can be achieved by applying:
 Principle of least commitment: the interface of an
object provides its essential behavior, and nothing
more
 Principle of least astonishment: an abstraction
captures the entire behavior of some object, no more
and no less, and offers no surprises or side effects that
go beyond the scope of the abstraction
Abstract Data Type (ADT)
 An ADT is a mathematical model of a data
structure that specifies the type of data stored, the
operations supported on them and the type of
parameters of the operations.
 Specifies what each operation does, but not how it
does it
Encapsulation
 Encapsulation hides the details of the
implementation of an object
 Typically, the structure of an object is hidden, as well as
the implementation of its methods.
 Encapsulation is the process of compartmentalizing the
elements of an abstraction that constitute its structure and
behavior;
 Encapsulation serves to separate the contractual interface of
an abstraction and its implementation.
Encapsulation
Encapsulation
 Encapsulation is most often achieved through information
hiding (not just data hiding), which is the process of hiding
all the secrets of an object that do not contribute to its
essential characteristics
Data/Information Hiding
Access
House
X ModifyX () Modify X
Private data – hidden from others
Function to safeguard the private data
Data Hiding
 "... the purpose of hiding is to make inaccessible
certain details that should not affect other parts of a
system.“ [Ross et al, 1975]
Data Hiding
 Data must be hidden/ private
 Read access through read() functions
 Write access through write() functions
 For each data,
 Allow both read and write
 Allow read only
 Allow write only
 No access
Encapsulation / Data Hiding
void modifyX (int newVal) {
if (newVal > 100) or (newVal < 0) {
return error;
}
else
X = newVal
}
void readX() {
return X;
}
Abstraction & Encapsulation
 Complementary concepts:
 The abstraction of an object should precede the decisions about its
implementation.
 Once an implementation is selected, it should be treated as a secret
of the abstraction and hidden from most clients i.e. encapsulated
 “For abstraction to work, implementations must be encapsulated
 Abstraction:
 focuses on the observable behavior of an object
 Encapsulation:
 focuses on the implementation that gives rise to this behavior
Anatomy of a Class
PRIVATE PUBLIC
Data
Private
Functions
Read/ Write
Functions
Constructors/
Destructors
ADT Functions
Pop(), Insert ()
Public Interface
Class
• Realization of an ADT
• State /fields /data
members
• Behavior /methods
/member functions
• Public Interface: signatures
(names, return types, argument
types) of a class’s public member
functions, only part of the class
that can be accessed by a user of
the class
Class
• It defines the data being stored and the operations
supported by the objects that are instances of the
class
• Every class must have two parts:
• an interface – what? – Abstraction
• an implementation – how? – Encapsulation
Abstraction Encapsulation
 External Interface
 The interface of a class
captures only its outside
view, encompassing
abstraction of the
behavior common to all
instances of the class.
 Internal Implementation
 The implementation of a
class comprises the
representation of the
abstraction as well as the
mechanisms that achieve
the desired behavior.
Class, Abstraction & Encapsulation
Abstraction Encapsulation
 Exposes Generic /
Generalized Features
 The interface of a class is
the one place where we
assert all of the
assumptions that a client
may make about any
instances of the class
 Hides implementation
details
 The implementation
encapsulates details
about which no client
may make assumptions.
Class, Abstraction & Encapsulation
In C++ a Class embodies both abstraction and encapsulation
Please read: http://www.tonymarston.co.uk/php-mysql/abstraction.txt
Point Product
class Point
{
public:
Point (double xval, double yval);
void move(double dx, double dy);
double get_x() const;
double get_y() const;
private:
double x;
double y;
};
class Product
{
public:
Product();
void read();
bool is_better_than(Product b) const;
void print() const;
private:
string name;
double price;
int score;
};
Examples
Objects
 Object
 Instantiation of a class
 Initialization of Objects
 Constructors
 Called automatically every time an object is created, ensures proper initialization
 Overcome the problem of improper initialization in procedural languages
 Resource De-allocation
 Destructors
 Ensures de-allocation of resources before the object dies, or goes out of scope
 Overcome memory leaks etc. in procedural languages
Objects
 Life-cycle of an Object
 Born Healthy
 Properly initialized by use of constructors
 Lives Safely
 Using read/write functions, ensure data integrity
 Dies Cleanly
 Using destructors
References
 [Lafore] Chapter 1
 [Booch et al] Chapters 1 & 2
 [Deital & Deital] Chapter 3
 [Horstmann & Budd] Chapter 5
 http://www.tonymarston.co.uk/php-
mysql/abstraction.txt

Abstraction file

  • 1.
    Recap: Object OrientedApproach  Four major elements:  Abstraction  Encapsulation  Modularity  Hierarchy  Three minor elements:  Typing  Concurrency  Persistence
  • 2.
  • 3.
    Abstraction  Dahl, Dijkstra,and Hoare suggest that “abstraction arises from a recognition of similarities between certain objects, situations, or processes in the real world, and the decision to concentrate upon these similarities and to ignore for the time being the differences” [42].
  • 4.
    Abstraction  An abstractiondenotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.
  • 6.
    Abstraction: Perspective ofUser Parent Child Name Class Roll No Mobile No Employee Name Id No Mobile No Tax Payer Name Pan No Annual Return Bank Customer Name Pan No Acct No Acct Type Loyalty Program Member Name Card No Points
  • 7.
    Abstraction  An abstractionfocuses on the outside view of an object and so serves to separate an object’s essential behavior from its implementation.  Deciding on the right set of abstractions for a given domain is the central problem in object-oriented design.
  • 8.
    Abstraction  Abstraction orseparation of behavior / implementation can be achieved by applying:  Principle of least commitment: the interface of an object provides its essential behavior, and nothing more  Principle of least astonishment: an abstraction captures the entire behavior of some object, no more and no less, and offers no surprises or side effects that go beyond the scope of the abstraction
  • 9.
    Abstract Data Type(ADT)  An ADT is a mathematical model of a data structure that specifies the type of data stored, the operations supported on them and the type of parameters of the operations.  Specifies what each operation does, but not how it does it
  • 10.
    Encapsulation  Encapsulation hidesthe details of the implementation of an object  Typically, the structure of an object is hidden, as well as the implementation of its methods.  Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior;  Encapsulation serves to separate the contractual interface of an abstraction and its implementation.
  • 11.
  • 12.
    Encapsulation  Encapsulation ismost often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics
  • 13.
    Data/Information Hiding Access House X ModifyX() Modify X Private data – hidden from others Function to safeguard the private data
  • 14.
    Data Hiding  "...the purpose of hiding is to make inaccessible certain details that should not affect other parts of a system.“ [Ross et al, 1975]
  • 15.
    Data Hiding  Datamust be hidden/ private  Read access through read() functions  Write access through write() functions  For each data,  Allow both read and write  Allow read only  Allow write only  No access
  • 16.
    Encapsulation / DataHiding void modifyX (int newVal) { if (newVal > 100) or (newVal < 0) { return error; } else X = newVal } void readX() { return X; }
  • 17.
    Abstraction & Encapsulation Complementary concepts:  The abstraction of an object should precede the decisions about its implementation.  Once an implementation is selected, it should be treated as a secret of the abstraction and hidden from most clients i.e. encapsulated  “For abstraction to work, implementations must be encapsulated  Abstraction:  focuses on the observable behavior of an object  Encapsulation:  focuses on the implementation that gives rise to this behavior
  • 18.
    Anatomy of aClass PRIVATE PUBLIC Data Private Functions Read/ Write Functions Constructors/ Destructors ADT Functions Pop(), Insert () Public Interface Class • Realization of an ADT • State /fields /data members • Behavior /methods /member functions • Public Interface: signatures (names, return types, argument types) of a class’s public member functions, only part of the class that can be accessed by a user of the class
  • 19.
    Class • It definesthe data being stored and the operations supported by the objects that are instances of the class • Every class must have two parts: • an interface – what? – Abstraction • an implementation – how? – Encapsulation
  • 20.
    Abstraction Encapsulation  ExternalInterface  The interface of a class captures only its outside view, encompassing abstraction of the behavior common to all instances of the class.  Internal Implementation  The implementation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior. Class, Abstraction & Encapsulation
  • 21.
    Abstraction Encapsulation  ExposesGeneric / Generalized Features  The interface of a class is the one place where we assert all of the assumptions that a client may make about any instances of the class  Hides implementation details  The implementation encapsulates details about which no client may make assumptions. Class, Abstraction & Encapsulation In C++ a Class embodies both abstraction and encapsulation Please read: http://www.tonymarston.co.uk/php-mysql/abstraction.txt
  • 22.
    Point Product class Point { public: Point(double xval, double yval); void move(double dx, double dy); double get_x() const; double get_y() const; private: double x; double y; }; class Product { public: Product(); void read(); bool is_better_than(Product b) const; void print() const; private: string name; double price; int score; }; Examples
  • 23.
    Objects  Object  Instantiationof a class  Initialization of Objects  Constructors  Called automatically every time an object is created, ensures proper initialization  Overcome the problem of improper initialization in procedural languages  Resource De-allocation  Destructors  Ensures de-allocation of resources before the object dies, or goes out of scope  Overcome memory leaks etc. in procedural languages
  • 24.
    Objects  Life-cycle ofan Object  Born Healthy  Properly initialized by use of constructors  Lives Safely  Using read/write functions, ensure data integrity  Dies Cleanly  Using destructors
  • 25.
    References  [Lafore] Chapter1  [Booch et al] Chapters 1 & 2  [Deital & Deital] Chapter 3  [Horstmann & Budd] Chapter 5  http://www.tonymarston.co.uk/php- mysql/abstraction.txt

Editor's Notes

  • #2 By major, we mean that a model without any one of these elements is not object oriented. By minor, we mean that each of these elements is a useful, but not essential, part of the object model.
  • #4 Abstraction is one of the fundamental ways that we as humans cope with complexity.
  • #9 Abelson and Sussman call this behavior/implementation division an abstraction barrier [45] achieved by applying the principle of least commitment, through which the interface of an object provides its essential behavior, and nothing more [46]. We like to use an additional principle that we call the principle of least astonishment, through which an abstraction captures the entire behavior of some object, no more and no less, and offers no surprises or side effects that go beyond the scope of the abstraction. Square (Coordinates, Color)
  • #11  Bundling together of data and functions that operate on data
  • #12 Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns. For example, consider again the structure of a plant. To understand how photosynthesis works at a high level of abstraction, we can ignore details such as the responsibilities of plant roots or the chemistry of cell walls. Similarly, in designing a database application, it is standard practice to write programs so that they don’t care about the physical representation of data but depend only on a schema that denotes the data’s logical view [52]. In both of these cases, objects at one level of abstraction are shielded from implementation details at lower levels of abstraction.
  • #13 Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside view at another level of abstraction. The underlying representation of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity.
  • #15 there are degrees of information hiding. For example, at the programming language level, C++ provides for public, private, and protected members ([Ellis and Stroustrup, 1990]), and Ada has both private and limited private types ([ARM, 1983]). Confusion can occur when people fail to distinguish between the hiding of information, and a technique (e.g., abstraction) that is used to help identify which information is to be hidden. Programming languages have long supported encapsulation. For example, subprograms (e.g., procedures, functions, and subroutines), arrays, and record structures are common examples of encapsulation mechanisms supported by most programming languages. Newer programming languages support larger encapsulation mechanisms, e.g., "classes" in Simula ([Birtwistle et al. 1973]), Smalltalk ([Goldberg and Robson, 1983]), and C++, "modules" in Modula ([Wirth, 1983]), and "packages" in Ada.
  • #16 Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside view at another level of abstraction. The underlying representation of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity. If encapsulation was "the same thing as information hiding," then one might make the argument that "everything that was encapsulated was Also hidden." This is obviously not true. For example, even though information may be encapsulated within record structures and arrays, this information is usually not hidden (unless hidden via some other mechanism). It is indeed true that encapsulation mechanisms such as classes allow some information to be hidden. However, these same encapsulation mechanisms also allow some information to be visible. Some even allow varying degrees of visibility, e.g., C++'s public, protected, and private members.
  • #18 Simply stated, the abstraction of an object should precede the decisions about its implementation. Once an implementation is selected, it should be treated as a secret of the abstraction and hidden from most clients. Abstraction and encapsulation are complementary concepts: Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods. “No part of a complex system should depend on the internal details of any other part” [50]. Whereas abstraction “helps people to think about what they are doing,” encapsulation “allows program changes to be reliably made with limited effort” [51]. “For abstraction to work, implementations must be encapsulated” [53].
  • #19 Principle of encapsulation – data private; read/write functions – Implementation function, reasons for which the class exists In OOP we say that objects are members of classes. What does this mean? A class is thus a description of a number of similar objects. This fits our non-technical understanding of the word class. An object is often called an “instance” of a class.
  • #20 In C++ every object must belong to a class. A class is a data type, just like int or double. However, classes are programmer-defined, whereas int and double are defined by the designers of the C++ language.
  • #21 “For abstraction to work, implementations must be encapsulated” [53]. In practice, this means that each class must have two parts: an interface and an implementation. The interface of a class captures only its outside view, encompassing our abstraction of the behavior common to all instances of the class. The implementation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior. The interface of a class is the one place where we assert all of the assumptions that a client may make about any instances of the class; the implementation encapsulates details about which no client may make assumptions.
  • #22 If the class’s implementation changes, the class’s clients should not be required to change. • Interfaces define and standardize the ways in which things such as people and systems interact. • A class’s public interface (p. 85) describes the public member functions that are made available to the class’s clients. The interface describes what services (p. 85) clients can use and how to request those services, but does not specify how the class carries out the services. • Separating interface from implementation (p. 84) makes programs easier to modify. Changes in the class’s implementation do not affect the client as long as the class’s interface remains unchanged. • A function prototype (p. 85) contains a function’s name, its return type and the number, types and order of the parameters the function expects to receive. • Once a class is defined and its member functions are declared (via function prototypes), the member functions should be defined in a separate source-code file. • For each member function defined outside of its corresponding class definition, the function name must be preceded by the class name and the binary scope resolution operator (::, p. 86).
  • #25 * Each class should provide a constructor (p. 77) to initialize an object of the class when the object is created. A constructor must be defined with the same name as the class. • A difference between constructors and functions is that constructors cannot return values, so they cannot specify a return type (not even void). Normally, constructors are declared public. • C++ requires a constructor call at the time each object is created, which helps ensure that every object is initialized before it’s used in a program. • A constructor with no parameters is a default constructor (p. 77). If you do not provide a constructor, the compiler provides a default constructor. You can also define a default constructor explicitly. If you define a constructor for a class, C++ will not create a default constructor.