COSC2767: Object-Oriented Programming

COSC2767: Object-Oriented Programming Haibin Zhu, Ph. D. Professor of Computer Science Nipissing University

Lecture 2 • Object-Oriented Design, Classes and Methods

Why Design ? • Object-oriented thinking begins with object-oriented design • It is the easiest way to give the student an appreciation of the problems of programming in the large (realistic modern software development). • Without understanding programming in the large, one cannot understand the importance of OOP

Activities in Software Development • Problem Analysis • Program Design • Coding • Documenting • Testing • Maintenance

Remember • Be clear about what you are trying to build. • Successful software development is a long term activity. • The systems that we build tend to be at the limit of the complexity that we and our tools can handle. • There are no cookbook methods that can replace intelligence, experience, and good taste in programming.

Remember • Experimentation is essential for all non-trivial software development. • Design and programming are iterative activities. • The different phases of a software project cannot be strictly separated. • Programming and design cannot be considered without also considering the management of these activities.

Strategy • There is only one basic way to deal with complexity: Divide and Conquer. • Systems can be divided into modules(Objects or Classes). • The challenge is to ensure effective communication between different parts of the program without destroying the divisions.

Objectives • We are concerned with producing software that satisfies the users’ requirements. • The primary means to do so is to produce software with a clean internal structure. • The Tasks of OO Design: • To specify: • The needed classes (or components) • The interface

The Need for a Clean Internal Structure To simplify: • Testing • Porting • Maintenance • Extension • Re-organization • Understanding

Characteristics of Successful Software It has an extended life where it might be: • worked on by succession of programmers and designers • ported to new hardware • adapted to unanticipated uses

Some Issues of Design • Identify Components • Postponing Decisions • Preparing for Changes • Coupling and Cohesion • Two views of a Software System • Formalize the Interface • Naming • Documentation

Identify Components • A component is simply an abstract entity that can perform tasks or fulfill some responsibilities. • It may eventually be turned into a class, a function, a module, or something else. • A component must have a small, well-defined set of responsibilities. • A component should interact with other components to the minimal extent possible.

Postponing Decisions • Many decisions can be ignored for the moment • Only need to note that somehow the user can manipulate

Preparing for Change • Your design team should also keep in mind that change is inevitable. Users requirements change with experience, hardware changes, government regulations change. • Try to predict the most likely sources of change, and isolate the effect. Common changes include interfaces, file formats, communication protocols. • Isolate interfaces to hardware that is likely to change. • Reduce dependency of one software component on another. • Keep accurate record of the reasoning behind every major decision in the design documentation.

Design for Change • The system must be designed to remain as simple as possible under a sequence of changes. • We must aim for • Flexibility • Extensibility • Portability • OOD can support the above.

Coupling and Cohesion • The separation of tasks into the domains of different components should be guided by the concepts of coupling and cohesion. • Cohesion is the degree to which the tasks assigned to a component seem to form a meaningful unit. Want to maximize cohesion. • Coupling is the degree to which the ability to fulfill a certain responsibility depends upon the actions of another component. Want to minimize coupling.

Parnas' Principles • The developer of a software component must provide the intended user with all the information needed to make effective use of the services provided by the component, and should provide no other information. • The implementer of a software component must be provided with all the information necessary to carry out the given responsibilities assigned to the component, and should be provided with no other information.

Public and Private View • Public view - those features (data or behavior) that other components can see and use • Private view - those features (data or behavior) that are used only within the component

Formalize the Interface • The general structure of each component is identified. • Components with only one behavior may be made into functions. • Components with many behaviors are probably more easily implemented as classes. • Names are given to each of the responsibilities - these will eventually be mapped on to procedure names. • Information is assigned to each component and accounted for. • Scenarios are replayed in order to ensure all data is available.

Naming • The selection of names is an important task. • Names should be evocative in the context of the problem. • Names should be short. • Names should be pronounceable (read them out load). • Names should be consistent within the project. • Avoid digits within a name.

Documentation • The user manual describes the application as seen by the user. • Quality • System Design Documentation

User Manual • Does not depend upon the implementation, so can be developed before the implementation. • Can naturally flow from the process of walking through scenarios. • Can be carried back to the clients to make sure the users and the implementers have the same ideas.

Quality • You should always remember that the primary measure of quality is the degree to which your customers (clients) are satisfied with your product. • Since often customers do not know exactly what it is they want, it is important to work with the client early in the design phase to make sure the system your are developing is the desired product. One very important way to do this is to create the user manual even before the software is written.

System Design Documentation • Record the decisions made during the process of system design. • Record the arguments for and against any major decision, and the factors influencing the final choice. • Use graphs (UML) for the major components. • Maintain a log or diary of the process schedule. • Important to produce this while the ideas are fresh, not in hindsight when many details will have been forgotten. • Note the code only records the outcome of decisions, not factors that lead up to decisions being made.

Implement and Test Subsystems • Classic techniques, such as stepwise refinement, are used to implement each of the subsystems. • Subsystems are validated in isolation. • Informal proofs of correctness for the subsystem are developed. • Identify necessary conditions for correct functioning. Try to minimize conditions, and test input values whenever possible. • Software testing is used as a confidence building measure.

Integration and Testing • Components are slowly integrated into completed system. • Stubs can be used to perform testing all during integration. • Errors discovered during integration to cause reinvestigation of validation techniques performed at the subsystem level.

Maintenance and Evolution • Software does not remain fixed after the first working version is released. • Errors or bugs can be discovered. Must be corrected. • Requirements may change. Say as a result of government regulations, or standardization among similar products. • Hardware may change. • Users expectations may change. Greater functionality, more features. Often as a result of competition from similar products. • Better documentation may be required. • A good design recognizes the inevitability of change, and plans an accommodation for these activities from the very beginning.

Common Design Flaws • Direct modification • Components that make direct modification of data values in other components are a direct violation of encapsulation. • Such coupling makes for inflexible designs. • Too Much Responsibility (or services, methods) • Components with too much responsibility are difficult to understand and to use. • Responsibility should be broken into smaller meaningful packages and distributed. • No Responsibility • Components with no responsibility serve no purpose. • Often arise when designers equate physical existence with logical design existence. • Components with unused responsibility • Usually the result of designing software components without thinking about how they will be used. • Misleading Names • Names should be short and unambiguously indicate what the responsibilities of the component involve.

Classes and Methods • Same Ideas, Different Terms • Encapsulation and Instantiation • Internal and External Views • Behavior and State • Class Definitions • Methods • Variations on Classes

Same Ideas, Different Terms • All OOP languages have the following concepts, although the terms they use may differ: • classes, object type, factory object • instances, objects • message passing, method lookup, member function invocation, method binding • methods, member function, method function • inheritance, subclassing

Encapsulation and Instantiation • Encapsulation - The purposeful hiding of information, thereby reducing the amount of details that need to be remembered/communicated among programmers. • A Service View - The ability to characterise an object by the service it provides, without knowing how it performs its task. • Instantiation - The ability to create multiple instances of an abstraction.

Common Behavior and State • A class can also be viewed as a combination of behavior and state. • Behavior: The actions that an instance can perform in response to a request. Implemented by methods. • State: The data that an object must maintain in order to successfully complete its behavior. Stored in instance variables (also known as data members, or data fields).

Design Steps of OOD • Find the Concepts/Classes and their most fundamental relationships. • Refine the Classes by specifying the sets of Operations on them • classify these operations: constructors, destructors, etc. • consider minimalism, completeness, and convenience

Design Steps (cont’d) • Refine the classes by specifying their dependencies on other classes: • Inheritance dependencies • Composition dependencies • Use dependencies • Specify the interfaces for the classes: • separate functions into public and protected operations • specify the exact type of the operations on the classes.

Finding Classes • Good design must capture and model some aspects of reality. • Look at the application rather than the computer abstractions. • Usually nouns correspond to classes and verbs represent functions. • Discussions with experts in the application domain.

Behavior and State • All classes can be characterized by two aspects: • The behavior of an object class is the set of actions a component can perform. The complete set of behavior for an object is sometimes called the protocol. • The state of an object represents all the information (data values) held within an object. • Notice that it is common for behavior to change state. For example, the edit behavior of a recipe may change the preparation instructions, which is part of the state.

Example • When ordering new videotapes from a supplier, the store manager creates a purchase order, fills in the date, the supplier’s name , address, and enters a list ofvideotapes to be ordered. The purchase order is added to a permanent list of purchases. When one or more video tapes are received from a supplier, a clerk locates the original purchase order and makes a record of each tape that was received. A record of the videotape is then added to the store’s inventory. When all tapes listed on a particular purchase order have been received, the manager sends a payment to the supplier and the purchase order is given a completion date.

Specifying operations • Consider how an object of the class is constructed, copied, and destroyed. • Define the minimal set of operations required by the concept the class is representing. • Consider which operations could be added for notational convenience and include only a few really important ones. • Consider which operations are to be virtual. • Consider what commonality of naming and functionality can be achieved across all the classes of the component.

Operations on a Class • Foundation: • Constructors and destructors • Selectors( or Accessors): • Operations that do not modify the state of an object. • Modifiers(or Setters): • Operations that modify the state of an object. • Conversion Operators: • Operations that produce an object of another type based on the value (state) of the object to which they are applied. • Iterators: • Operations that processes data members containing collections of objects.

Specifying Dependencies • The key dependencies to consider in the context of design are inheritance and use relationships. • Overuse can lead to inefficient and incomprehensible designs.

Specifying Interfaces • Private functions are not considered at this stage. • The interface should be implementation independent (more than one implementation should be possible). • All operators in a class should support the same level of abstraction.

Reorganizing the Class Hierarchy • Typically, the initial organization of classes may not be adequate and therefore, we may have to reorganize to improve the design and/or implementation. • The two most common reorganizations of a class hierarchy are • factoring of two classes into a new class • splitting a class into two new ones.

Experimentation and Analysis • Prototyping is frequently used for experimenting. • Different aspects of a system may be prototyped independently, such as the graphical user interface. • Analysis of a design and/or implementation can be an important source of insight.

The Definition of Class • Class ::=<n, d, m, x>, where • n is an Identification or a name of the class; • d is the space description (template) for memory; • m is the set of methods (or services, operations) the objects of this class can make; and • x is a unified interface of all the objects of the class.

Class Definition in C++ class PlayingCard { public: enum Suits {Spade, Diamond, Club, Heart}; Suits suit () { return suitValue; } int rank () { return rankValue; } private: Suits suitValue; int rankValue; };

Visibility Modifiers • The terms public and private are used to differentiate the internal and external aspects of a class. • public features can be seen and manipulated by anybody -- they are the external (interface or service) view. • private features can be manipulated only within a class. They are the internal (implementation) view. • Typically methods are public and data fields are private, but either can be placed in either category.

Methods • A name that will be matched to a message to determine when the method should be executed. • A signature, which is the combination of return type and argument types. Methods with the same name can be distinguished by different signatures. • A body, which is the code that will be executed when the method is invoked in response to a message.

Constructor • class PlayingCard { • // constructor, initialize new playing card • public PlayingCard (Suits is, int ir) • { suit = is; rank = ir; faceUp = true; } • ... • } • A constructor is a method that is used to initialize a newly constructed object. In C++, Java, C# and many other languages it has the same name as the class. • More about constructors in the next lecture.

Accessor (or getter) Methods • An accessor (or getter) is a method that simply returns an internal data value: • class PlayingCard { • ... • // operations on a playing card • public int rank () { return rankValue; } • public Suits suit () { return suitValue; } • ... • private int rankValue; • }

Why Use an Accessor? • You can make the data field read-only. • It provides better documentation that the data field is accessible • It makes it easier to later change the access behavior (count number of accesses, whatever).

COSC2767: Object-Oriented Programming