Dr. Ruby Lanting-Casaul Educational Foundation, Inc.
Tomas Cabiles St., San Juan, Tabaco City, Albay
Email Address: casaul.lanting.college@gmail.com
Tel. No. 052 – 431 - 3783
COURSE INFORMATION
Course Code
SDF104
Course Title
Credit Units
Pre-requisite
Term, School Year
Delivery Mode
Schedule
Instructor
E-mail
Consultation Schedule/Venue
LMS (Link/Passcode)
Object-Oriented Programming
Three (3)
None
First Semester, 2020-2021
Synchronous and Asynchronous
Friday (9:00-10:30)
MS. FUNNY E. BASQUIÑAS
funnybasquinas19@gmail.com
Computer Laboratory
Google Classroom (pxiq2ii)
LESSON 1: INTRODUCTION TO
OBJECT-ORIENTED PROGRAMMING
LESSON OBJECTIVES:
At the end of this lesson, the students should be able to:
1. define what an Object-Oriented Programming is;
2. understand the brief history of Object-Oriented Programming; and
3. differentiate procedure-oriented programming from OOP.
LESSON DISCUSSION:
Introduction
 With the advent of languages such as C, structured programming
became very popular and was the main technique of the 1980’s. Structured
programming was a powerful tool that enabled programmers to write
moderately complex programs fairly easily. However, as the programs grew
larger, even the structured approach failed to show the desired result in terms
of bug-free, easy-to- maintain, and reusable programs.
Definition of Important concepts:
a) Object Oriented Programming (OOP) - is an approach to program
organization and development that attempts to eliminate some of the pitfalls
of conventional programming methods by incorporating the best of structured
programming features with several powerful new concepts.
 It is a new way of organizing and developing programs and has
nothing to do with any particular language. However, not all languages are
suitable to implement the OOP concepts easily.
Figure 1
b) Procedure-Oriented Programming - In the procedure oriented
approach, the problem is viewed as the sequence of things to be done such
as reading, calculating and printing such as COBOL, FORTRAN and C. The
primary focus is on functions. A typical structure for procedural programming
is shown in Figure 2.
- The technique of hierarchical decomposition has been used to specify
the tasks to be completed for solving a problem.
 Procedure oriented programming basically consists of writing a list
of instructions for the computer to follow, and organizing these instructions
into groups known as functions. We normally use flowcharts to organize these
actions and represent the flow of control from one action to another. In a
multi-function program, many important data items are placed as global so
that they may be accessed by all the functions. Each function may have its
own local data. Global data are more vulnerable to an inadvertent change by
a function. In a large program it is very difficult to identify what data is used
by which function.
 In case we need to revise an external data structure, we also need to
revise all functions that access the data. This provides an opportunity for bugs
to creep in. Another serious drawback with the procedural approach is that
we do not model real world problems very well. This is because functions are
action-oriented and do not really corresponding to the element of the
problem.
Figure 2
Some Characteristics exhibited by procedure-oriented
programming are:
• Emphasis is on doing things (algorithms).
• Large programs are divided into smaller programs known as
functions.
• Most of the functions share global data.
• Data move openly around the system from function to function.
• Functions transform data from one form to another.
• Employs top-down approach in program design.
LET’S KNOW THE HISTORY
 The functional and imperative programming paradigms we use today
were first explored mathematically in the 1930s with lambda calculus and the
Turing machine, which is alternative formulations of universal computation
(formalized systems which can perform general computation). The Church
Turing Thesis showed that lambda calculus and Turing machines are
functionally equivalent — that anything that can be computed using a Turing
machine can be computed using lambda calculus, and vice versa.
Lambda calculus represents a top-down, function application approach to
computation, while the ticker tape/register machine formulation of the Turing
machine represents a bottom-up, imperative (step-by-step) approach to
computation.
 Low level languages like machine code and assembly appeared in the
1940s, and by the end of the 1950s, the first popular high-level languages
appeared. Lisp dialects are still in common use today, including Clojure,
Scheme, AutoLISP, etc. FORTRAN and COBOL both appeared in the 1950s
and are examples of imperative high-level languages still in use today, though
C-family languages have replaced both COBOL and FORTRAN for most
applications.
 Both imperative programming and functional programming have their
roots in the mathematics of computation theory, predating digital computers.
“Object-Oriented Programming” (OOP) was coined by Alan Kay circa 1966 or
1967 while he was at grad school.
 Ivan Sutherland’s seminal Sketchpad application was an early
inspiration for OOP. It was created between 1961 and 1962 and published in
his Sketchpad Thesis in 1963. The objects were data structures representing
graphical images displayed on an oscilloscope screen, and featured
inheritance via dynamic delegates, which Ivan Sutherland called “masters” in
his thesis. Any object could become a “master”, and additional instances of
the objects were called “occurrences”. Sketchpad’s masters share a lot in
common with JavaScript’s prototypal inheritance.
The Big Idea
“I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in
mind.” ~ Alan Kay, OOPSLA ‘97
Alan Kay coined the term “object oriented programming” at grad
school in 1966 or 1967. The big idea was to use encapsulated mini-computers
in software which communicated via message passing rather than direct data
sharing — to stop breaking down programs into separate “data structures”
and “procedures”.
“The basic principal of recursive design is to make the parts have the
same power as the whole.” ~ Bob Barton, the main designer of the B5000, a
mainframe optimized to run Algol-60.
Smalltalk was developed by Alan Kay, Dan Ingalls, Adele Goldberg, and others
at Xerox PARC. Smalltalk was more object-oriented than Simula — everything
in Smalltalk is an object, including classes, integers, and blocks (closures).
The original Smalltalk-72 did not feature subclassing. That was introduced in
Smalltalk-76 by Dan Ingalls.
While Smalltalk supported classes and eventually subclassing, Smalltalk
was not about classes or subclassing things. It was a functional language
inspired by Lisp as well as Simula. Alan Kay considers the industry’s focus on
subclassing to be a distraction from the true benefits of object oriented
programming.
“I’m sorry that I long ago coined the term “objects” for this topic because it
gets many people to focus on the lesser idea. The big idea is messaging.”
~ Alan Kay
In a 2003 email exchange, Alan Kay clarified what he meant when he
called Smalltalk “object-oriented”:
“OOP to me means only messaging, local retention and protection and hiding
of
state-process,
and
extreme
late-binding
of
all
things.”
~ Alan Kay
In other words, according to Alan Kay, the essential ingredients of OOP
are:Message passing, Encapsulation, Dynamic binding notably, inheritance
and subclass polymorphism were NOT considered essential ingredients of
OOP by Alan Kay, the man who coined the term and brought OOP to the
masses.
The Essence of OOP
The combination of message passing and encapsulation serve some
important purposes: (1) Avoiding shared mutable state by encapsulating
state and isolating other objects from local state changes. The only way to
affect another object’s state is to ask (not command) that object to change it
by sending a message. State changes are controlled at a local, cellular level
rather than exposed to shared access. (2) Decoupling objects from each
other — the message sender is only loosely coupled to the message receiver,
through the messaging API. (3) Adaptability and resilience to changes at
runtime via late binding. Runtime adaptability provides many great benefits
that Alan Kay considered essential to OOP.
These ideas were inspired by biological cells and/or individual
computers on a network via Alan Kay’s background in biology and influence
from the design of Arpanet (an early version of the internet). Even that early
on, Alan Kay imagined software running on a giant, distributed computer (the
internet), where individual computers acted like biological cells, operating
independently on their own isolated state, and communicating via message
passing.
“I realized that the cell/whole-computer metaphor would get rid of data
[…]” ~ Alan Kay
By “get rid of data”, Alan Kay was surely aware of shared mutable state
problems and tight coupling caused by shared data — common themes today.
But in the late 1960s, ARPA programmers were frustrated by the need to
choose a data model representation for their programs in advance of building
software. Procedures that were too tightly coupled to particular data structures
were not resilient to change. They wanted a more homogenous treatment of
data.
“[…] the whole point of OOP is not to have to worry about what is
inside an object. Objects made on different machines and with different
languages should be able to talk to each other […]” ~ Alan Kay
Objects can abstract away and hide data structure implementations.
The internal implementation of an object could change without breaking other
parts of the software system. In fact, with extreme late binding, an entirely
different computer system could take over the responsibilities of an object,
and the software could keep working. Objects, meanwhile, could expose a
standard interface that works with whatever data structure the object
happened to use internally. The same interface could work with a linked list, a
tree, a stream, and so on.
Alan Kay also saw objects as algebraic structures, which make certain
mathematically provable guarantees about their behaviors:
“My math background made me realize that each object could have
several algebras associated with it, and there could be families of these, and
that
these
would
be
very
useful.”
~ Alan Kay
This has proven to be true, and forms the basis for objects such as
promises and lenses, both inspired by category theory.
The algebraic nature of Alan Kay’s vision for objects would allow objects to
afford formal verifications, deterministic behavior, and improved testability,
because algebras are essentially operations which obey a few rules in the form
of equations.
In programmer lingo, algebras are like abstractions made up of
functions (operations) accompanied by specific laws enforced by unit tests
those functions must pass (axioms/equations).
Those ideas were forgotten for decades in most C-family OO languages,
including C++, Java, C#, etc., but they’re beginning to find their way back
into recent versions of most widely used OO languages.
You might say the programming world is rediscovering the benefits of
functional programming and reasoned thought in the context of OO
languages.
Like JavaScript and Smalltalk before it, most modern OO languages are
becoming more and more “multi-paradigm languages”. There is no reason to
choose between functional programming and OOP. When we look at the
historical essence of each, they are not only compatible, but complementary
ideas.
LESSON ACTIVITIES:
Instruction: Choose from one of these key concepts in Object-Oriented
Programming and research about this.
Key concepts:
1.
2.
3.
4.
5.
6.
Object
Class
Polymorphism
Encapsulation
Inheritance
Abstraction
Reference:
https://medium.com/javascript-scene/the-forgotten-history-of-oop
88d71b9b2d9f#:~:text=%E2%80%9CObject%2DOriented%20Programming%E2%8
0%9D%20(,his%20Sketchpad%20Thesis%20in%201963