CSC/ECE 517 Fall 2011/ch4 5a sp

Introduction to Object Oriented Design(OOD)

This page serves as a knowledge source for understanding the concepts covered in Lecture14- Introduction to Object Oriented Design(OOD).

Overview

Lecture 14 <ref name="CSC517">OOD, CSC 517 Lecture14</ref> of CSC 517 covered various aspects of the object oriented design including the basics of OOD principles along with the design criteria and the Class Responsibility Collaboration card tool.

Object-oriented design can be defined as the process of planning a 'system of interacting objects' for the purpose of solving a software problem. It is one approach to software design that revolves around the basic entity called object. An object contains data and procedures grouped together to represent an entity(class). Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis.

Basic Object Oriented Concepts

The five basic concepts of object-oriented design are the implementation level features that are built into the programming language. They can be considered as the general vocabulary required to implement an object oriented design solution <ref name="OOD vocabulary">OOD Vocabulary, OOD Vocabulary</ref>. These terms are explained in brief:

• Object: A class is a tight coupling or association of data structures with the methods or functions that act on the data. An object is an instance of the class serving a separate function. An object is defined by its properties.

• Information Hiding/Encapsulation: The ability to protect some components of the object from external entities i.e. protecting parts of the program from extensive modification if the design decision is changed. This is achieved by language keywords to enable a variable to be declared as private or protected to the owning class.

• Inheritance: inheritance is a way to reuse code of existing objects and thus ability for a class to extend or override functionality of another class. Inheritance is realized by establishing a subtype from an existing object, or both, depending upon programming language support.

• Polymorphism: The ability to replace an object with its subobjects. The ability of an object-variable to contain, not only that object, but also all of its subobjects.

• Interface: Interface can be defined as the ability to defer the implementation of a method or the process to define the functions or methods signatures without implementing them.

Criteria for Elegant Software Design

Listed below are the different criteria for elegant software design. There are nine different design considerations, out of which the first five address correctness of the software and the rest consider the performance.

Usability: Usability can be measured by the ease of use for the client.

Completeness: A software program/application is complete if it solves all the client needs.

Robustness: A good design is one that can deal with unusual situations gracefully and avoid crashing.

Efficiency: The application performs the necessary computations in a reasonable amount of time.

Scalability: An application is scalable if it performs correctly and efficiently when the problems grow in size by several orders of magnitude.

Readability: If it is easy for another programmer to read and understand the design and code, the design is readable.

Modifiability: If the software can easily be enhanced or restricted by adding new features or removing old features without breaking existing code, the design is modifiable.

Reusability: Resuability checks the ability to be reused in another completely different setting.

Simplicity: The simplicity criteria check if the design and/or the implementation unnecessarily complex.

Design Concepts

Listed below are the major components for building a design solution for a problem:

• Defining objects, creating class diagram from conceptual models and map the entities to classes.

• Identifying attributes for each class/entity.

• Use design patterns <ref name="Design Patterns">Design Patterns Elements of Reusable Object Oriented Software by Erich Gamma</ref> to solve a problem that can be used in many different situations and/or applications.

• Identifying persistent objects i.e. to know objects that last longer than a single runtime.

• Identify the application framework to take advantage of the existing code and reuse whatever possible.

Design Principles

Listed below are the main principles that need to be followed for building an effective design solution<ref name="Design Principles">Object Oriented Design Principles</ref>:

• Open Close Principle: This principle states that software entities like classes, modules and functions should be open for extension but closed for modifications.

• Dependency Inversion Principle: This principle states that high-level modules should not depend on low-level modules and both should depend on abstractions.

• Interface Segregation Principle: This principle states that clients should not be forced to depend upon interfaces that they do not use.

• Single Responsibility Principle: This principle states that a class should have only reason to change.

• Liskov's Substitution Principle: This principle states that derived types must be completely substitutable for their base types.

OOD: The CRC Method

Class-Responsibility-Collaboration card is a very useful tool for software design that determine the classes needed along with the types of interactions.

CRC cards are created from index cards on which are written:

1. The class name
2. Its Super and Sub classes (if applicable)
3. The responsibilities of the class.
4. The names of other classes with which the class will collaborate to fulfill its responsibilities.
5. Author

The use of small card minimizes the complexity of the design. It forces the designer to refrain from giving the class too many responsibilities. These cards are portable and thus can easily be laid out on a table and re-arranged while discussing the design with other people.

A specification for the program being designed is studied and then the cards that need to be created are designed. The cards contain the class names(generally nouns) along with the responsibilities(verbs) and the collaborators associated with the class. When choosing classes, we need to make sure that the class name,

1. is a singular noun,
2. does not really have the same functionality as some other class,
3. is not simply a primitive type,(because u need not write code for primitive types)

Example 1: Flight reservation system

Requirements for the Flight Reservation System

• The mission is to allow round-trip airline tickets to be bought over the Web.
  
• Each customer specifies an origination airport, a destination airport, and dates for outbound and return flights.
  
• The customer reserves one outbound flight and one return flight from a menu presented by the system.
  
• Each choice that the system presents consists of one or more flight segments (there may be a change of planes).
  
• The customer may buy tickets for one or more passengers.
  
• No more tickets can be sold for a flight than there are seats on the plane.
  
• Each passenger is assigned to a specific seat.
  
• The system calculates the total cost of the tickets by adding the cost of the individual segments.
  
• If dissatisfied with the cost, the customer may select alternate flights.
  
• After a customer has bought a ticket, (s)he will be e-mailed a confirmation
  

References

<references />