1: Introduction to Object (1)

Size: px

Start display at page:

Download "1: Introduction to Object (1)"

Allan Wilkerson
5 years ago
Views:

1 1: Introduction to Object (1) 김동원

2 Overview (1) The progress of abstraction Smalltalk Class & Object Interface The hidden implementation Reusing the implementation Inheritance: Reusing the interface Has-a vs. Is-a Relationships Is-a vs. Is-like-a relationships Interchangeable objects with polymorphism Thinking in C++ Page 1

3 Overview (2) Creating and destroying objects Exception handling: Dealing with errors Analysis and design 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 Thinking in C++ Page 2

4 The progress of abstraction All programming languages provide abstractions Fortran, BASIC, and C Abstractions of assembly language Primary abstraction is the structure of the computer rather than the structure of the problem you are trying to solve The programmer must establish the association between the machine model (solution space) and the model of the problem that is actually being solved (problem space) Required to perform this mapping between solution space and problem space The produced program is difficult to write and expensive to maintain Thinking in C++ Page 3

5 The progress of abstraction The object-oriented approach Provides tools for the programmer to represent elements in the problem space Describe the problem in terms of the problem, rather than in terms of the computer where the solution will run More flexible and powerful Thinking in C++ Page 4

6 Smalltalk The first successful object-oriented language One of the languages upon which C++ is based Characteristics 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 All objects of a particular type can receive the same messages Thinking in C++ Page 5

7 Class & Object Class First introduces a new type into a program in the Simula- 67 A data type A set of objects that have identical characteristics (data elements) and behaviors (functionality) By adding new data types specific to your needs Object (Instance) Variable of a type (class) Receive messages or requests Thinking in C++ Page 6

8 Interface The requests of an object are defined by its interface A simple example Light lt; lt.on(); Thinking in C++ Page 7

9 The hidden implementation Access control for member functions of a class Reasons Reduce bug Keep client programmers hands off portions they shouldn t touch To allow the library designer to change the internal workings of the class without worrying about how it will affect the client programmer C++ Three explicit keywords to set the boundaries in a class public, private, and protected Thinking in C++ Page 8

10 Reusing the implementation It takes experience and insight to produce a good design One of the greatest advantages that object-oriented programming languages provide The simplest way to reuse a class To just use an object of that class directly Place an object of that class inside a new class This concept is called composition or aggregation Ex) UML (Unified Modeling Language ) Thinking in C++ Page 9

11 Inheritance: Reusing the interface One of the Important point Package data and functionality together by concept These concepts are expressed as fundamental units in the programming language by using the class keyword If we can take the existing class, clone it, and then make additions and modifications to the clone This is effectively what you get with inheritance If the original (base, super or parent) class is changed, the modified clone (inherited or derived) also reflects those changes Thinking in C++ Page 10

12 Inheritance: Reusing the interface A base type contains all of the characteristics and behaviors that are shared among the types derived from it Thinking in C++ Page 11

13 Inheritance: Reusing the interface (Example) The base type is shape, and each shape has a size, a color, a position, and so on Each shape can be drawn, erased, moved, colored, etc Specific types of shapes are derived (inherited): circle, square, triangle, and so on, each of which may have additional characteristics and behaviors Thinking in C++ Page 12

14 Inheritance: Reusing the interface (Example) Thinking in C++ Page 13

15 Inheritance: Reusing the interface (Example) Overriding Although inheritance may sometimes imply that you are going to add new functions to the interface, that s not necessarily true More important way to differentiate your new class is to change the behavior of an existing base-class function Thinking in C++ Page 14

16 Has-a vs. Is-a Relationships Has-a Is-a Thinking in C++ Page 15

17 Is-a vs. Is-like-a relationships Pure substitution (is-a) The derived type is exactly the same type as the base class since it has exactly the same interface Is-like-a The new type can still be substituted for the base type, but the substitution isn t perfect The new type has the interface of the old type but it also contains other functions Can t really say it s exactly the same Thinking in C++ Page 16

18 Interchangeable objects with polymorphism Dealing with type hierarchies Often want to treat an object not as the specific type that it is but instead as its base type Allows you to write code that doesn t depend on specific types In the shape example Functions manipulate generic shapes without respect to whether they re circles, squares, triangles, and so on Unaffected by the addition of new types Adding new types is the most common way to extend an object-oriented program to handle new situations Thinking in C++ Page 17

19 Interchangeable objects with polymorphism Extending a program is easy by deriving new subtypes Reduce the cost of software maintenance Thinking in C++ Page 18

20 Interchangeable objects with polymorphism (Example) Early-binding The compiler generates a call to a specific function name, and the linker resolves this call to the absolute address of the code to be executed Late-binding The compiler cannot determine the address of the code until runtime To perform late binding, the C++ compiler inserts a special bit of code in lieu of the absolute call Thinking in C++ Page 19

21 Interchangeable objects with polymorphism (Example) Thinking in C++ Page 20

22 Creating and destroying objects For maximum runtime speed The storage and lifetime can be determined while the program is being written, by placing the objects on the stack or in static storage Using the stack or static storage area Relatively fast for dynamic allocation Dynamic allocation Create objects dynamically in a pool of memory called the heap If you need a new object, using the new keyword When you re finished with the storage, you must release it using the delete keyword The C++ language does not support a garbage collector Thinking in C++ Page 21

23 Exception handling: Dealing with errors Error handling One of the most difficult issues Hard to design a good error-handling scheme Many languages simply ignore the issue Exception handling Wires error handling directly into the programming language and sometimes even the operating system Exception Object Thrown from the site of the error and can be caught by an appropriate exception handler designed to handle that particular type of error Thinking in C++ Page 22

24 Exception handling: Dealing with errors Exception Provide a way to recover reliably from a bad situation Instead of just exiting the program, you are often able to set things right and restore the execution of a program produces much more robust systems Thinking in C++ Page 23

25 Analysis and design Some sort of process will generally get you on your way in a much better fashion than simply beginning to code It s crucial to move fairly quickly through analysis and design, and to implement a test of the proposed system Analysis paralysis No matter how much analysis you do There are some things about a system that won t reveal themselves until design time More things that won t reveal themselves until you re coding, or not even until a program is up and running Thinking in C++ Page 24

26 Analysis and design Keep in mind what you re trying to discover 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? If you come up with nothing more than the objects and their interfaces, then you can write a program The process can be undertaken in five phases Thinking in C++ Page 25

27 Phase 0: Make a plan Procedure design or requirement analysis Decide what steps you re going to have in your process If your plan is let s jump in and start coding, fine Sometimes that s appropriate when you have a wellunderstood problem It divides the project into more bite-sized pieces and makes it seem less threatening Add the milestones offer more opportunities for celebration Thinking in C++ Page 26

28 Phase 1: What are we making? The requirements analysis in the previous phase Make a list of the guidelines we will use to know when the job is done and the customer is satisfied A contract between you and the customer The system specification Here s a description of what the program will do (not how) to satisfy the requirements Top-level exploration into the problem A discovery of whether it can be done How long it will take To save time To lists and basic diagrams Thinking in C++ Page 27

29 Phase 1: What are we making? Use case Identify key features in the system These are essentially descriptive answers to questions like 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) Thinking in C++ Page 28

30 Phase 1: What are we making? (Example) Suppose you are designing an auto-teller The use case for a particular aspect of the functionality of the system The auto-teller does in every possible situation Each of these situations is referred to as a scenario A use case can be considered a collection of scenarios Use case diagrams are intentionally simple To prevent you from getting bogged down in system implementation details prematurely Does not need to be terribly complex, even if the underlying system is complex Thinking in C++ Page 29

31 Phase 1: What are we making? (Example) Each stick person An actor, which is typically a human or some other kind of free agent The box The boundary of your system The ellipses The use cases Descriptions of valuable work that can be performed with the system The lines between the actors and the use cases represent the interactions Thinking in C++ Page 30

32 Phase 2: How will we build it? Determine classes and interactions the Class-Responsibility-Collaboration (CRC) card Start out with a set of blank 3 by 5 cards and write on them Each card represents a single class, and on the card you write The name of the class It s important that this name capture the essence of what the class does, so that it makes sense at a glance The responsibilities of the class This can typically be summarized by just stating the names of the member functions The collaborations of the class what other classes does it interact with? Thinking in C++ Page 31

33 Phase 2: How will we build it? If you can t fit all you need to know about a class on a small card, the class is too complex Either you re getting too detailed, or you should create more than one class The ideal class should be understood at a glance Once you ve come up with a set of CRC cards, you may want to create a more formal description of your design using UML Thinking in C++ Page 32

34 Five stages of object design 1. Object discovery Occurs during the initial analysis of a program 2. Object assembly As you re building an object you ll discover the need for new members 3. System construction The need for communication and interconnection with other objects in the system may change the needs of your classes or require new classes 4. System extension As you add new features to a system you may discover that your previous design doesn t support easy system extension With this new information, you can restructure parts of the system, possibly adding new classes or class hierarchies Thinking in C++ Page 33

35 Five stages of object design 5. Object reuse This is the real stress test for a class If someone tries to reuse it in an entirely new situation, they ll probably discover some shortcomings As you change a class to adapt to more new programs, the general principles of the class will become clearer, until you have a truly reusable type However, don t expect most objects from a system design to be reusable (my person opinion and experience that classes is built in the system construction procedure) Thinking in C++ Page 34

36 Guidelines for object development Thinking about developing your classes 1. Let a specific problem generate a class, then let the class grow and mature during the solution of other problems 2. Remember, discovering the classes you need (and their interfaces) is the majority of the system design If you already had those classes, this would be an easy project 3. Don t force yourself to know everything at the beginning; learn as you go This will happen anyway 4. Start programming; get something working so you can prove or disprove your design Thinking in C++ Page 35

37 Guidelines for object development Always keep it simple Little clean objects with obvious utility are better than big complicated interfaces When decision points come up, use an Occam s Razor approach Consider the choices and select the one that is simplest, because simple classes are almost always best Start small and simple, and you can expand the class interface when you understand it better Thinking in C++ Page 36

38 Phase 3: Build the core Not a one-pass process Iteratively build the system Find the core of your system architecture Needs to be implemented in order to generate a running system You re Creating a framework that you can build upon with further iterations Discover changes and improvements Test verify the requirements and use cases When the core of the system is stable, you re ready to move on and add more functionality Thinking in C++ Page 37

39 Phase 4: Iterate the use cases Add is a small project in itself You add a feature set during an iteration Each use case package of related functionality that you build into the system all at once, during one iteration Give you a better idea of what the scope of a use case Gives more validation to the idea of a use case Stop iterating Achieve target functionality External deadline arrives The customer can be satisfied with the current version Thinking in C++ Page 38

40 Advantages of the iterative process Reveal and resolve critical risks early The customers have ample opportunity to change their minds Programmer satisfaction is higher The project can be steered with more precision Important benefit is the feedback to the stakeholders Reduce or eliminate the need for mind-numbing status meetings Increase the confidence and support from the stakeholders Thinking in C++ Page 39

41 Phase 5: Evolution Traditionally called maintenance Add features that the customer forgot to mention Fix the bugs that show up Add new features as the need arises You need not fear modification Thinking in C++ Page 40

The object-oriented approach goes a step further by providing tools for the programmer to represent elements in the problem space.

The object-oriented approach goes a step further by providing tools for the programmer to represent elements in the problem space. 1 All programming languages provide abstractions. Assembly language is a small abstraction of the underlying machine. Many imperative languages (FORTRAN, BASIC, and C) are abstractions of assembly language.