Responsibilities and Collaborators

Once you havfe identified the classes, define their responsibilities. These may be things the class knows or things the class does.
For example, a CheckingAccount class might know the current balance in the account and the owner of the account.
These are things the checking account knows. The CheckingAccount class might also have to deduct money from the account when a check is written. This is something the class does.

In the process of identifying a class's responsibilities, you will probably discover that the class by itself doesn't know or can not do everything it needs to know or do to carry out its responsibilities. It needs to collaborate with other classes to fulfill its obligations. Objects are particular instances of a class that contain both the data that defines the object and the methods that operate on the object. Unlike procedural programming, OOP does not separate the data structures from the algorithms. They are both bundled together inside a class.

In OOP, classes collaborate with other classes to carry out all their necessary responsibilities. For example, the CheckingAccount class might need to collaborate with the Person class and the Transaction class to collect all the information required to generate a monthly statement, because a statement would contain information stored in all three classes. Thus, the final step in object-oriented analysis is to identify the class's collaborators. This style of analysis is called CRC modeling. CRC stands for Class-Responsibility-Collaborator.
Once a CRC model of a system has been built, the classes are defined. Each class has a public interface that is reflected in the CRC model. Each class also has a private implementation that is hidden from everything except the class itself. The private implementation can be changed without affecting the public interface.

Question: What is the concept behind Class-Responsibility-Collaborator Modeling, which is used within the context of object oriented analysis?

1. Introduction: Class-Responsibility-Collaborator (CRC) Modeling is a method utilized primarily within the domain of object-oriented analysis. Established as a means to facilitate the design and conceptualization of object-oriented software, CRC focuses on the identification of the key responsibilities and interactions between classes.
2. The Three Pillars:
   1. Class:
      At the core of the CRC model is the notion of a 'Class'. In object-oriented terminology, a class represents a blueprint for creating objects (a particular data structure). It embodies both data for the object and methods to manipulate this data.
   2. Responsibility:
      Responsibilities encompass the obligations or behaviors a class knows or performs. They can be broken down into:
      
      1. Knowing Responsibilities: The information a class maintains.
      2. Doing Responsibilities: Actions the class performs, computations it does, or decisions it makes.
   3. Collaborator:
      Collaborators are classes that assist the class in question in fulfilling its responsibilities. Collaboration implies a two-way communication. When one class relies upon another to realize its responsibilities, the relied-upon class becomes a collaborator.
3. The Mechanics of CRC Cards:
   Traditionally, CRC modeling is performed using index cards, with each card representing a single class.
   
   1. Layout:
      Each card is divided into three sections:
      1) Top: Contains the name of the class. 2) Middle: Lists the responsibilities of the class. 3) Bottom: Enumerates the collaborators of the class.
   2. Usage: During a design session, teams physically manipulate these cards to simulate the dynamics of the proposed system. The tangible nature of CRC cards promotes open communication, encourages team collaboration, and allows for the rapid reconfiguration of class structures.
4. Advantages of CRC Modeling:
   
   1. Simplicity: CRC modeling simplifies the design process by emphasizing conceptual clarity over syntactical rigor.
   2. Collaboration: The physical nature of CRC cards makes them apt for team-based design sessions, fostering communication and collective problem-solving.
   3. Flexibility: The ease of repositioning and amending CRC cards supports iterative design, enabling designers to quickly explore different design avenues.
5. Conclusion: Class-Responsibility-Collaborator (CRC) Modeling remains a robust tool in the repertoire of object-oriented analysts and designers. By decoupling the conceptual from the concrete, and emphasizing the core tenets of class interactions and responsibilities, CRC modeling presents an intuitive and effective approach to software design.

A (CRC) Class Responsibility Collaborator model is a collection of standard index cards that have been divided into three sections, as depicted in Figure 1.

1. A class represents a collection of similar objects,
2. a responsibility is something that a class knows or does, and
3. a collaborator is another class that a class interacts with to fulfill its responsibilities.

In recent years developers have come to appreciate more and more the value of designs based on proven solutions. Patterns and collaborations allow the modelers to define standard approaches to solving common problems. A pattern may then be applied to a variety of specific situations, bringing with it a combination of predefined roles and interactions. Patterns and collaborations may be identified and defined at many levels of abstraction, cataloged, and documented for others to use. This approach brings reuse out of the realm of pure code and into every phase of the modeling effort, from requirements and architecture through implementation.

Another approach that can be used for identifying classes is Classes, Responsibilities, and Collaborators (CRC) developed by Cunningham, Wilkerson, and Beck. Classes, Responsibilities, and Collaborators, more technique than method, is used for identifying classes responsibilities and therefore their attributes and methods.