Classes and Objects: The Building Blocks of the Object-Oriented Paradigm

1. Classes and Objects:The Building Blocks of the Object-Oriented Paradigm Presented by Tara Struble

2. Introduction to Classes and Objects • All implementation details should be hidden from users behind a consistent public interface. • Allows designer to change implementation whenever necessary. • Greatly simplifies maintenance.

3. Messages and Methods • Message  name of an object behavior. • Method  implementation of a message. • Protocol  list of messages to which an object can respond.

4. Users of a class must be dependent on its public interface, but a class should not be dependent on its users. • Minimize the number of messages in the protocol of a class. • Implement a minimal public interface that all classes understand. • (operations such as copy, equality testing, printing, parsing from an ASCII description)

5. Do not put implementation details such as common-code private functions into the public interface of a class. • Do not clutter the public interface of a class with items that users of that class are not able to use or are not interested in using.

6. Class Coupling and Cohesion • The goal is tight cohesion within classes and loose coupling between classes. • Tight cohesion implies that the code making up the function is closely related. • Loose coupling implies that when one function wishes to use another, it should enter and exit the function from one point.

7. Basic forms of coupling • Nil coupling two classes that have no dependency on each other. • Export coupling  one class is dependent on the public interface of the other. • Overt coupling  one class uses the implementation details of another class with permission. • Covert coupling  same as overt coupling, except that no permissions are granted.

8. Classes should only exhibit nil or export coupling with other classes. • A class should capture one and only one key abstraction. • Keep related data and behavior in one place. • Spin off non-related information into another class.

9. Dynamic Semantics • Collection of all possible states of a class’s objects, as well as the legal transitions between them. • Allows an object to respond differently to the same message sent at different times.

10. Abstract Classes • Do not know how to instantiate objects. • Used primarily for inheritance hierarchies.

11. Roles Versus Classes • Be sure the abstractions that you model are classes and not simply the roles objects play. • The distinction is based on differing behavior.