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. All implementation details should be hidden from users behind a consistent public interface. Allows designer to change implementation whenever necessary. Allows designer to change implementation whenever necessary. Greatly simplifies maintenance. Greatly simplifies maintenance.

3. Messages and Methods Message  name of an object behavior. Message  name of an object behavior. Method  implementation of a message. Method  implementation of a message. Protocol  list of messages to which an object can respond. 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. 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. Minimize the number of messages in the protocol of a class. Implement a minimal public interface that all classes understand. Implement a minimal public interface that all classes understand. (operations such as copy, equality testing, printing, parsing from an ASCII description) (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 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. 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. 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. 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. 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. Nil coupling  two classes that have no dependency on each other. Export coupling  one class is dependent on the public interface of the 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. 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. Covert coupling  same as overt coupling, except that no permissions are granted.

8. Classes should only exhibit nil or export coupling with other classes. Classes should only exhibit nil or export coupling with other classes. A class should capture one and only one key abstraction. A class should capture one and only one key abstraction. Keep related data and behavior in one place. Keep related data and behavior in one place. Spin off non-related information into another class. 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. 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. Allows an object to respond differently to the same message sent at different times.

10. Abstract Classes Do not know how to instantiate objects. Do not know how to instantiate objects. Used primarily for inheritance hierarchies. 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. Be sure the abstractions that you model are classes and not simply the roles objects play. The distinction is based on differing behavior. The distinction is based on differing behavior.