Introduction to Classes

1
Introduction to Classes
2
Terms and Concepts

• A class is ...
• The most important building block of any
  object-oriented system.
• A description of a set of objects that share the
  same attributes and behaviors.
• A blueprint for creating an object.
• An abstraction (simplification) of reality.
• A representation of a software thing, a hardware
  thing, or even a conceptual thing.
• Graphically represented as a rectangle.

3
Terms and Concepts

• All classes have
• Names - Used to distinguish one class from
  another. A class must have a name.
• Attributes - Member data.
• Operations (behaviors) - Member functions.
• Stereotypes - Documentation used to categorized
  class members.
• Responsibilities - Documents the purpose of the
  class.
• Attributes and operations are the most important
  features of a class definition.
• A class usually collaborate with other classes.

4
Terms and Concepts

• Class names are
• Extracted from the problem domain (statement).
• Nouns or noun phrases.
• Concise and descriptive.
• Class attributes are
• Usually nouns or noun phrases.
• Extracted or inferred from the problem statement.
• Used to represent properties of the enclosing
  class.
• Determine the state of an object.

5
Terms and Concepts

• Class operations (behaviors) are
• Verbs or verb phrases.
• Inferred from the problem statement.
• Provide a requested service.
• Class responsibility
• Is a contract or obligation of a class to the
  users of the class.
• Maps directly to the Responsibility field of a
  CRC card.
• CRC - Class Responsibility Collaboration

6
Class Artifact
7
Common Modeling Techniques

• Identify the classes that are to be included in
  the design.
• Formulate a problem statement.
• Focus on the nouns in the problem statement.
• Use CRC (Class, Responsibility, Collaboration)
  cards or use-cases to isolate each class.

8
Common Modeling Techniques

• Determine the responsibilities of each class.
• Even out the work load between classes.
• A class with too much responsibility should be
  broken up into multiple classes.
• A class with too little responsibility should be
  absorbed into another class.
• Group together classes that work toward a common
  goal.
• Packages (directories) may be used to group
  related classes into a higher level of
  abstraction.
• Packages may contain other packages.

9
Common Modeling Techniques

• Classes should exhibit high cohesion and low
  coupling.
• A class should have a single well-defined
  purpose.
• This promotes software reusability
• A class should interact with a limited number of
  other classes.
• This simplifies modifications to the program.

10
Common Modeling Techniques

• Feel free to model abstract (non-software) things
  (such as people) that are outside of the system
  boundaries.
• Occasionally built-in data types (int, float,
  char, etc.) are modeled as classes, although this
  is rare.

11
Class Relationships
12
Terms and Concepts
13
Terms and Concepts

• A dependency is ...
• A type of relationship that can exist between two
  classes.
• An indication that one class uses another
  class.
• If the used class changes it can have an impact
  on the using class.
• Graphically represented as a dashed line with an
  open arrowhead on one end.
• Rarely labeled.
• The used class is frequently an argument to one
  of the member functions of the using class.
• The used class has no knowledge of the using
  class.

14
Terms and Concepts
15
Terms and Concepts

• A generalization is
• A type of relationship that can exist between two
  classes. One of the classes is the base (or
  parent) class the other class is the derived (or
  child) class.
• Used to show a kind-of relationship.
• Another name for inheritance.
• All OO programming languages support single
  inheritance some (C) also support multiple
  inheritance.
• Graphically represented by a solid line with an
  open triangular arrowhead on the base class end.
• The parent class has no knowledge of the child
  class.

16
Terms and Concepts
17
Terms and Concepts

• An association is
• A type of relationship that can exist between one
  or more classes.
• Used to show a knows-a relationship.
• Either unidirectional or bi-directional.
• Graphically represented by a solid line which may
  optionally be labeled and have a name direction
  indicator.
• A peer relationship.
• Association names are verbs or verb phrases.
• The same class can be on both ends of a binary
  association.

18
Terms and Concepts

• Associations may optionally have role names and
  multiplicity symbols on either end of the
  association line (next to the class icon).
• Role
• The face that a class on one end of an
  association presents to the class on the other
  end of the association.
• A class can participate in many associations and
  thus have multiple (different) roles.
• Role names are nouns.
• Role names are usually used in place of
  association names.

19
Terms and Concepts

• Multiplicity
• Indicates how many object may be connected across
  an instance of an association.
• Aggregation is
• A relationship between two classes.
• A form of association.
• Used to show a has-a or a whole-part
  relationship.
• Graphically represented as a solid line with an
  open diamond on the whole end.
• Aggregations and associations are implemented in
  exactly the same way. The difference is
  entirely conceptual.

20
Terms and Concepts
21
Terms and Concepts

• Composition is
• A relationship between two classes.
• A strong form of association.
• Used to show a contains-a or a whole-part
  relationship.
• Graphically represented as a solid line with a
  solid diamond on the whole end.
• Composition relationships and associations are
  not implemented in exactly the same way.
• If the whole object is destroyed, the part
  object will also be destroyed.
• The whole and part have concurrent lifetimes.

22
Terms and Concepts
23
Common Modeling Techniques

• Modeling inheritance
• Make it a priority to look for possible
  inheritance relationships. This will reduce
  code redundancy.
• Use the ClassA is-a-kind-of ClassB test.
• Do not model relationships using multiple
  inheritance unless the implementation language
  supports multiple inheritance. This will save
  programmers having to develop messy work-arounds.
  
• Look for classes that have similar attributes and
  behaviors and then factor those attributes and
  behaviors into a common base class.

24
Common Modeling Techniques

• Modeling dependency, association, aggregation and
  composition relationships.
• It is not always easy to determine which is the
  best relationship to use. It all has to do with
  your perspective of the problem domain.
• There is not always one best solution.
• Personal experience is your most valuable
  modeling tool.
• CRC cards are helpful.