Chapter 12 OOP Using C++

Chapter 12 OOP Using C++
• 12.1 OOP Language
Requirements
• 12.2 ADTs in Non-OOP
Languages
• 12.3 Clients and
Manufacturers
• 12.4 Reuse and
Inheritance
• 12.5 Polymorphism
• 12.6 Language
Complexity
• 12.7 C++OOPB and
wagon
• 12.8 Platonism: Tabula
Rasa Design
• 1 2.9 Design Principles
• 12.10 Schema. Diagrams.
and Tools
• 12.11 Design Patterns
• 12.12 C++:A Critique
• Summary
• Exercises
Chapter 12 OOP Using C++
• C++ is a hybrid language.
• Object-oriented programming(O0P) and
C++ were embraced by the industry very
quickly.
• The key new ingredients are inheritance and
polymorphism, that is, its capability to
assume many forms.
12.1 OOP Language Requirements
• OOP Language Characteristics
• Encapsulation with data hiding
E n c a p s u l a t i o n w i t h d a t a h i d i n g
: The ability to
distinguish an object's internal state and behavior
from its external state and behavior.
• Type-extensibility
T y p e - e x t e n s i b i l i t y
: The ability to add user-defined
types to augment the native types.
• Inheritance
I n h e r i t a n c e
: The ability to create new types by
importing or reusing the description of existing
types.
• Polymorphism with dynamic binding
P o l y m o r p h i s m w i t h d y n a m i c b i n d i n g
: The ability
of objects to be responsible for interpreting
function invocation.
12.2 ADTs in Non-OOP Languages
• Existing languages and methodology
supported much of the OOP methodology
by combining language features with
programmer discipline.
12.3 Clients and Manufacturers
• Black Box for the Client
– Simple to use, easy to understand, and familiar
– Cheap, efficient, and powerful
– In a component relationship within the system
• Black Box for the Manufacturer
– Easy to reuse and modify, and hard to misuse
and reproduce
– Cheap, efficient, and powerful
– Profitable to produce with a large client base
12.4 Reuse and Inheritance
• Library creation and reuse are crucial
indicators of successful language strategies.
• The OOP Design Methodology
• 1.
Decide on an appropriate set of ADTs.
• 2.
Design in their relatedness, and use
inheritance to share code and interface.
• 3.
Use virtual functions to process related
objects dynamically.
12.5 Polymorphism
• Types
of Polymorphism
• 1. Coercion (ad hoc polymorphism): A
function or operator works on several
different types by converting their values to
the expected type.
• 2.
Overloading (ad hoc polymorphism): A
function is called based on its signature
defined as the list of argument types in its
parameter list.
12.5 Polymorphism
• 3.
Inclusion (pure polymorphism): A type is
a subtype of another type. Functions
available for the base type will work on the
subtype.
• 4. Parametric polymorphism (pure
polymorphism): The type is left unspecified
and is later instantiated.
12.6 Language Complexity
12.7 C++OOP Bandwagon
• OOP using C++ has gained dazzling
acceptance in industry, despite
acknowledged flaws.
• OOP = type-extensibility
t y pe - e xt e n s i bi l i t y
+ polymorphism.
pol y m or ph i s m .
12.8 Platonism: Tabula Rasa Design
• Tabula rasa-given an empty slate-no simple
methodology exists, because each design
must be strongly tied to the problem domain
and reflect its abstractions.
• Discovering these abstractions is a design
philosophy we call platonism
pl at on i s m
.
.
12.8 Platonism: Tabula Rasa Design
• In the Platonic paradigm, there is an ideal
object.
12.9 Design Principles
• Most programming should involve the use
of existing designs.
• Occam's razor is a useful design principle. It
states that entities should not be multiplied
beyond necessity-or beyond completeness,
invertibility, orthogonality, consistency,
simplicity, efficiency, and expressiveness.
– Invertibility
I n v e r t i b i l i t y
means that the program should
have member functions that are inverses.
12.9 Design Principles
– Completeness
C o m p l e t e n e s
is best seen in Boolean algebra,
where the nand operation suffices to generate
all possible Boolean expressions.
– Orthogonality
O r t h o g o n a l i t y
is a principle that says each
element of a design should integrate and work
with all other elements without overlapping or
being redundant.
– Hierarchy
H i e r a r c h y
is captured through inheritance.
Designs should be hierarchical.
12.10 Schema. Diagrams. and Tools
• CRC stands for class, responsibility, and
collaboration.
– A responsibility is an obligation the class must keep.
– A collaborator is another object that cooperates with
this object to provide some overall set of behaviors.
– The front of the card corresponds to public behavior.
– The back of the card can be used to show
implementation details, including ISA, LIKEA, and
HASA relationships.
12.10 Schema. Diagrams. and Tools
12.10 Schema. Diagrams. and Tools
• Wasserman-Pircher diagrams are derived
from entity-relation modeling and structured
design.
12.10 Schema. Diagrams. and Tools
• A sophisticated integrated software
environment that uses these to develop OOP
code is provided by Interactive
Development Environments (IDE), San
Francisco, California.
12.10 Schema. Diagrams. and Tools
12.11 Design Patterns
• Reuse is a primary theme in modern programming.
• Thus the iterator classes of STL are a design
d e s i g n
pattern.
p a t e r n .
• Elements of a Design Pattern
– 1. The pattern terminology. For example, Iterator
I t e r a t o r
.
.
– 2.
The problem and conditions. For example, visitation
v i s i t a t i o n
over a container.
– 3.
The solution. For example, pointer-like objects with
a common interface.
– 4. The evaluation. For example, the trade-off between
defining an iterator on a vector or using a native array.
12.11 Design Patterns
• A design pattern is an abstraction that
suggests a useful solution to a particular
programming problem.
• Design Patterns in This Text
itseragxhnPTDtn
• 1. Iterator
I t e r at or
.
.
• 2. Composite.
2. C om pos i t e .
• 3. Template method.