Chapter 1 Introduction to Objects

Outline of the chapter  The basic concepts of object-oriented programming (OOP)  An overview of OOP development methods 02/24

Progress of abstraction  All programming languages provide abstractions. Assembly language, Fortran, C and Basic, LISP,PROLOG.  establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solve.  As a result it is difficult to write and expensive to maintain the programs. 03/24

Progress of abstraction  The object-oriented approach goes a step farther by providing tools for the programmer to represent elements in the problem space.  Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run.  Each object looks quite a bit like a little computer: it has a state, and it has operations that you can ask it to perform. 04/24

Progress of abstraction Five basic characteristics of OOP  Everything is an object.  A program is a bunch of objects telling each other what to do by sending messages.  Each object has its own memory made up of other objects.  Every object has a type/class.  All objects of a particular type can receive the same messages. 05/24

An Object has an interface  Objects that are identical except for their state during a program’s execution are grouped together into “classes of objects”. (abstract data type)  create variables of a type (called objects or instances in object-oriented parlance)  manipulate those variables (called sending messages or requests; you send a message and the object figures out what to do with it). 06/24

An Object has an interface  a class describes a set of objects that have identical characteristics (data elements) and behaviors (functionality)  one of the challenges of object-oriented programming is to create a one-to-one mapping between the elements in the problem space and objects in the solution space. 07/24

An Object has an interface  The interface establishes what requests you can make for a particular object.  A type has a function associated with each possible request, and when you make a particular request to an object, that function is called.  This process is usually summarized by saying that you “send a message” (make a request) to an object, and the object figures out what to do with that message (it executes code). 08/24

An Object has an interface A simple example might be a representation of a light bulb: (is shown by UML) 09/24 Light lt; lt.on();

The hidden implementation  Access control Protect the portions the user should not touch. exposes only what’s necessary to user. Internal changed does not affect the users.  Just publish the necessary port of Class.  Class hidden the internal working to outside user.  Three key words( access specifier) public, protected, private 10/24

Reusing the implementation  Code reuse is one of the greatest advantages of OOP. improve efficiency and robust.  Methods of reuse: use the class directly.  Composition/Aggregation (“has-a” relationship )  simpler and more flexible Inheritance ( “is-a” relationship ) 11/24

Inheritance: reusing the interface Inheritance expresses this similarity between types using the concept of base types and derived types. A base type contains all of the characteristics and behaviors that are shared among the types derived from it. 12/24

Inheritance: reusing the interface  You create a base type to represent the core of your ideas about some objects in your system. From the base type, you derive other types to express the different ways that this core can be realized.  Derive class can have additional characteristics and different behavior. (for example trash)  Using inheritance to construct the hierarchy of class. 13/24

Inheritance: reusing the interface 14/24 The base type is “shape,” From this, specific types of shapes are derived (inherited): circle, square, triangle, and so on, each of which may have additional characteristics and behaviors. Some behaviors may be different, such as when you want to calculate the area of a shape. The type hierarchy embodies both the similarities and differences between the shapes.

Inheritance: reusing the interface 15/24  You have two ways to differentiate your new derived class from the original base class.  The first is simply add brand new functions to the derived class. These new functions are not part of the base class interface.

Inheritance: reusing the interface 16/24  The second and more important way to differentiate your new class is to change the behavior of an existing base-class function. This is referred to as overriding that function.

Inheritance: reusing the interface  Is-a vs. is-like-a relationships  Is-a relationship: has exactly the same interface, can be thought of as pure substitution.  is-like-a relationship: when you must add new interface elements to a derived type, thus extending the interface and creating a new type. The new type can still be substituted for the base type, but the substitution isn’t perfect because your new functions are not accessible from the base type. 17/24

Polymorphism  Treat an object not as the specific type that it is but instead as its base type. Old code unaffected by the addition of new type.  early binding (determine at compile time)  late binding (determine until runtime ) 18/24

Polymorphism  When move() called while ignoring the specific type of Bird, the right behavior will occur. 19/24

Polymorphism  Two technology to support polymorphism the first is virtual, the second is upcasting.  Key word : virtual State that you want a function to have the flexibility of late-binding properties.  Virtual functions allow you to express the differences in behavior of classes in the same family. Those differences are what cause polymorphic behavior. 20/24

Polymorphism 21/24  We call this process of treating a derived type as though it were its base type Upcasting.  To realize the polymorphism, we should use the pointer or reference.

Polymorphism void doStuff(Shape& s) { s.erase(); //... s.draw(); } Circle c; Triangle t; Square l; doStuff(c); doStuff(t); doStuff(l); 22/24

Creating and destroying objects  Two approach to create objects  The first is on the stack or in static storage maximum runtime speed sacrifice flexibility because you must know the exact quantity, lifetime, and type about objects automatically destroy  The second is create objects dynamically in a pool of memory called the heap use new and delete greater flexibility garbage collector 23/24

Exception handling  Exception handling wires error handling directly into the programming language and sometimes even the operating system  C++ exception handling centers around the use of the keyword try, catch, throw  it doesn’t need to interfere with your normally executing code  in order to indicate an error condition  provide a way to recover reliably from a bad situation 24/24

Analysis and Design  What are the objects? (How do you partition your project into its component parts?)  What are their interfaces? (What messages do you need to be able to send to each object?) /

Analysis and Design  Phase 0: Make a plan  Phase 1: What are we making  Phase 2: How will we build it  Phase 3: Build the core  Phase 4: Iterate the use cases  Phase 5: Evolution /

Phase 0: Make a plan  You must first decide what steps you’re going to have in your process.  The mission statement You won’t necessarily get it right the first time (you may be in a later phase of the project before it becomes completely clear), but keep trying until it feels right. /

Phase 1: What are we making  "Who will use this system?"  "What can those actors do with the system?"  "How does this actor do that with this system?"  "How else might this work if someone else were doing this, or if the same actor had a different objective?" (to reveal variations)  "What problems might happen while doing this with the system?" (to reveal exceptions) /

Phase 1: What are we making /

 Each stick person represents an “actor,” which is typically a human or some other kind of free agent  The box represents the boundary of your system.  The ellipses represent the use cases, which are descriptions of valuable work that can be performed with the system.  The lines between the actors and the use cases represent the interactions. /

Phase 2: How will we build it Class-Responsibility-Collaboration (CRC)  The name of the class.  The “responsibilities” of the class: what it should do.  The “collaborations” of the class: what other classes does it interact with? /

Phase 2: How will we build it Five phases of Object design  Object discovery.  Object assembly The internal needs of the object  System construction. facilitator or helper classes, such as a linked list,  System extension possibly adding new classes or class hierarchies  Object reuse change a class to adapt to more new programs better than an entirely new class /

Phase 2: How will we build it Guidelines for object development 1. Let a specific problem generate a class, then let the class grow and mature during the solution of other problems. 2. discovering the classes you need (and their interfaces) is the majority of the system design. 3. Don’t force yourself to know everything at the beginning; learn as you go. 4. Start programming; get something working so you can prove or disprove your design. Bad classes do not break good classes (class partition). 5. Always keep it simple. Start small and simple, and you can expand the class interface when you understand it better, but it’s difficult to remove elements from a class /

Phase 3: Build the core  This is the initial conversion from the rough design into a compiling and executing body of code that can be tested, and especially that will prove or disprove your architecture.  Your goal is to find the core of your system architecture that needs to be implemented in order to generate a running system, no matter how incomplete that system is in this initial pass. /

Phase 4: Iterate the use cases  You stop iterating when you achieve target functionality or an external deadline arrives and the customer can be satisfied with the current version.  open-source projects work exclusively in an iterative, high-feedback environment, which is precisely what makes them successful.  You can reveal and resolve critical risks early, the customers have ample opportunity to change their minds, programmer satisfaction is higher, and the project can be steered with more precision, more important is increase the confidence and support from the stakeholders. /

Phase 5: Evolution  maintenance  from “getting it to work the way it was really supposed to in the first place” to “adding features that the customer forgot to mention” to the more traditional “fixing the bugs that show up” and “adding new features as the need arises.” For the published software  1. to make some patches  2. to produce a higher version /

Plans pay off  No matter how minimal you choose to make it, some kind of plan will make a big improvement in your project as opposed to no plan at all.  Not only does it give you a program that’s easier to build and debug, but it’s also easier to understand and maintain, and that’s where the financial value lies. /

Extreme programming (plan) /

Extreme programming (design) /

Extreme programming (code) /

Extreme programming (test) /

Why C++ succeeds  C++ has been so successful is that the goal was not just to turn C into an OOP language  The goal of C++ is improved productivity.  C++ is designed to be practical; C++ language design decisions were based on providing the maximum benefits to the programmer. /

A better C  C++ has closed many holes in the C language and provides better type checking and compile-time analysis.  references  function overloading, which allows you to use the same name for different functions  namespaces improves the control of names /

You’re already on the learning curve  C++ is an extension to C, not a complete new syntax and programming model. It allows you to continue creating useful code, applying the features gradually as you learn and understand them.  all of your existing C code is still viable in C++, but because the C++ compiler is pickier, you’ll often find hidden C errors when recompiling the code in C++. /

Efficiency  it’s more important to create the model rapidly than to execute it rapidly.  the ability to directly write assembly language within a C++ program. (the same as to C)  the program speed for an object- oriented C++ program is closest to c. (about 10%)  more efficient than the C counterpart in design the program /

Systems are easier to express and understand  Classes designed to fit the problem tend to express it better. you’re describing your solution in the terms of the problem space (“Put the grommet in the bin”) rather than the terms of the computer.  easier to understand, easier to maintain in the program and documentation. /

Maximal leverage with libraries  A major goal in C++ is to make library use easier  bringing in a library means adding new types to the language  focus on what you want the library to do, not how you have to do it /

Source-code reuse with templates  The template feature in C++ performs the source code modification automatically, making it an especially powerful tool for reusing library code.  A type that you design using templates will work effortlessly with many other types.  Templates are especially nice because they hide the complexity of this kind of code reuse from the client programmer. /

Error handling  The worst thing is having an error buried somewhere with no clue as to where it came from in a large, complex program  C++ exception handling is a way to guarantee that an error is noticed and that something happens as a result. /

Programming in the large  C++ is designed to aid programming in the large, that is, to erase those creeping- complexity boundaries between a small program and a large one.  the compiler is aggressive about ferreting out bug-producing errors for small and large programs alike. /

Strategies for transition Guidelines in making the transition to OOP and C++  1. Training  2. Low-risk project  3. Model from success  4. Use existing class libraries  5. Don’t rewrite existing code in C++ /

Strategies for transition Management obstacles  1. Startup costs  2.Performance issues  3.Common design errors /

SUMMARY  why OOP is different,  why C++ in particular is different,  concepts of OOP methodologies,  issues in the transition to OOP and C++.  OOP is a well-designed program, easy to understand the code by reading it. a lot less code by reusing existing library code. /