• Classes and Objects
• Data Hiding
• Encapsulation
• Relationships betwen Classes
• Abstract Classes and Interfaces
• Exception Handling
• Design Patterns

• Focus on understanding real-world concepts
• This involves the natural combination of data and processes

• A Class (Two Related Definitions):
  • A definition of a set that is written in terms of the properties of the elements (i.e., an intensive definition of a set)
  • The set of elements so defined
• An Object:
  • An element of the set

• Think About Two Types of Characteristics:
  • State (i.e., attributes)
  • Behavior (i.e., operations)

    

• Use Abstraction:
  • Use important common characteristics
  • Ignore other characteristics

• State/Behavior of the Objects:
  • Instance variables
  • Instance methods
• State/Behavior of the Class:
  • Class variables
  • Class methods

• Messages:
  • Objects communicate with each other by sending messages
• Message Categories:
  • Messages often fall into categories (e.g., constructors, destructors, selectors/accessors, modifiers)
  • This categorization is an abstraction

• One object should never directly manipulate the attributes of another
• The first object should ask (by sending a message to) the second to change its state

• The process of combining the attributes and behaviors/activities/functionalities of an entity in a program unit

• Public: +
• Private: -
• Protected: #
• Package: ~

• The Process:
  • Initialize the state
  • Establish an Identity
• An Example:
  • 

• Association
• Aggregation ("Has-a")
• Specialization ("Is-a")

Class A is said to be associated with class B if an object in class A can send a message to an object of class B or if an object in class A can create, receive or return objects of class B.

Class A is said to depend on class B if method in an object of class A is passed an object of class B.

An object of class A is an aggregate of an object of class B if B is a part of A. It is also often called the "has a" relationship though the phrase "has a" is ambiguous (e.g., a car has a color and a car has a radiator mean very different things).

An object of class A is composed of an object of class B if B is a part of A and A controls the life of B (e.g., if A is destroyed then B will be destroyed). Thus a component can be associated with exactly one composite (making the multiplicity implictly 1).

An object of class A "is-an" object of class B if A is/does everything that B is/does and more.

• Definition:
  • A class that cannot be instantiated (often, though not necssarily, because it does not implement all of its methods)

    

• Rationale:
  • Many child classes may require the functionality included in the abstract class

• Purpose:
  • Provide a view of a set of services provided by a class
  • Represent a "contract"
• Example:
  • Sortable
  • 

• The Issue:
  • An object can be an instance of different classes within a single hierarchy
  • An object can realize many different interfaces
• The Implication:
  • Different behavior could be triggered by the same message
• Don't Be Confused:
  • When passing an object (that has many types) an overloaded method (different versions of which have parameters of these different types), a different mechanism is used to determine which method is called

• Purpose:
  • Allow one or more types to be specified externally
• UML:
  • 
• Uses:
  • Commonly used for collections (to make them type-safe)
  • Can also be used for other purposes (e.g., to specifiy the kind of measurement to use, to specify the kinds of messages that will be displayed)

• Purpose:
  • Group related functionality
• Differences from other classes:
  • Not "data types"
  • Can't be instantiated

• The Concept:
  • Group/organize components
• The Rationale:
  • "Chunking"
  • Provide a higher-level view (abstraction)
  • Increase cohesion and reduce coupling
  • Have an organizational role similar to directories/folders

• Packages define a namespace
  • Two packages can contain components with the same name
  • Package names can be prepended to class names (e.g., Plant.Leaf and Hierarchy.Leaf)
• Basic Notation:
  • 

• Handling Problems w/o Exceptions:
• Return a "special value"
• Examples: -1, null
• Exception Handling:
• An alternative return mechanism

          try 
          {
	       d = StringToDouble(s);
 
	       // If we get here things are OK
          } 
          catch (NumberFormatException nfe)
          {

	       // If we get here there was a problem
          }
          

• Defined:
  • "Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context." (Gamma, Helm, Johnson and Vlissides)
• Level of Abstraction:
  • Lower level than the architecture
  • Higher level than data structures and algorithms

• Types:
  • Creational (i.e. concerned with object creation)
  • Structural (i.e., concerned with the composition of objects)
  • Behavioral (i.e., concerned with interactions and responsibilities
• Benefits:
  • Simplifies the development of designs
  • Promotes better communication
  • May increase re-use and quality