Hubbry Logo
Class-responsibility-collaboration cardClass-responsibility-collaboration cardMain
Open search
Class-responsibility-collaboration card
Community hub
Class-responsibility-collaboration card
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Class-responsibility-collaboration card
Class-responsibility-collaboration card
Class-responsibility-collaboration card
View on Wikipedia
from Wikipedia

Class-responsibility-collaboration (CRC) cards are a brainstorming tool used in the design of object-oriented software. They were originally proposed by Ward Cunningham and Kent Beck as a teaching tool[1] but are also popular among expert designers[2] and recommended by extreme programming practitioners.[3] Author Martin Fowler has written that CRC cards may be a sensible means by which multiple alternative interactions may be quickly devised, as they avoid a great deal of drawing and erasing. CRC card sessions may be followed by the creation of sequence diagrams to capture interactions that are identified.

CRC cards are frequently employed during the design phase of system and software development to transition use-case descriptions into class diagrams, allowing a smoother transition with a greater overview and permitting developers to implement solutions with low binding and high cohesion.

CRC cards are usually created from index cards. Members of a brainstorming session will write one CRC card for each relevant class/object of their design. The card is partitioned into three areas:[1][2]

  1. On top of the card, the class name
  2. On the left, the responsibilities of the class
  3. On the right, collaborators (other classes) with which the class interacts to fulfill its responsibilities

Using small cards minimizes the complexity of the design, reduces class responsibilities and keeps designers focused on the essentials of the classes without exploring implementation details. Because the cards are portable, they can easily be laid out on a table and rearranged while discussing a design.

Creating CRC cards

[edit]

Creation of CRC cards normally begins with writing a scenario that identifies the major actors and actions. From the scenario, nouns should become classes, verbs become responsibilities and collaborators are the other cards with which the card will interact.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Class-responsibility-collaboration card

View on Grokipedia
from Grokipedia
A Class-Responsibility-Collaboration (CRC) card is a low-fidelity tool employed in to model the structure and interactions of classes through collaborative brainstorming sessions. Each CRC card, typically a standard , is divided into three sections: the top for the class name, the middle for listing the class's responsibilities (actions it performs or data it maintains), and the bottom for identifying collaborators (other classes with which it interacts to fulfill those responsibilities). Introduced by and in their 1989 as a pedagogical aid for teaching object-oriented thinking, CRC cards enable teams to physically manipulate cards during role-playing exercises, simulating object behaviors to uncover design insights without initial reliance on code or complex diagrams. The technique promotes agile principles by fostering group discussion and iterative refinement, helping designers identify emergent properties of a early in the development process. Responsibilities on a card are categorized as "doing" (services provided) or "knowing" (data attributes), while collaborators highlight dependencies, ensuring a focus on encapsulation and core to object-oriented paradigms. Originating from Cunningham's work at , CRC cards gained prominence in the 1990s as part of , influencing modern agile methodologies for and prototyping. Their simplicity—requiring only paper and markers—makes them accessible for diverse teams, from novices learning OOP to experienced architects refining large-scale systems. Beyond , CRC cards have been adapted for educational purposes, , and even non-technical domains like product development, where they serve as a versatile artifact for visualizing roles and relationships. Sessions often involve "walking through" scenarios by passing cards among participants, revealing inconsistencies or gaps in the proposed that might otherwise surface later in . While digital variants exist in tools like collaborative whiteboards, the original physical format remains valued for its tactile, distraction-free .

Overview

Definition and Purpose

Class-responsibility-collaboration (CRC) cards are index cards, either physical or digital, employed in to represent individual classes by detailing their responsibilities and the other classes with which they interact. Each card typically includes the class name at the top, followed by sections listing responsibilities—actions or knowledge the class manages—and collaborators, which are classes it relies on to fulfill those responsibilities. This format provides a lightweight, tangible way to model software components without delving into code syntax or implementation specifics. The primary purpose of CRC cards is to support collaborative brainstorming sessions, teach foundational object-oriented concepts, and aid in by emphasizing behavioral aspects and inter-class dependencies. They encourage teams to explore how classes encapsulate data and methods while interacting through messages, fostering a focus on high-level architecture rather than low-level details. By simulating class interactions in group exercises, CRC cards help identify design flaws early and promote iterative refinement of the system model. Invented in as a low-fidelity prototyping method, CRC cards were designed to make abstract object-oriented principles more accessible and experiential for learners and designers alike. This approach transforms theoretical ideas, such as encapsulation and polymorphism, into physical artifacts that can be manipulated during discussions. CRC cards promote by encouraging the assignment of a focused set of responsibilities to each class, aligning with of single responsibility to enhance maintainability and reduce between components. This emphasis on discrete roles helps ensure that classes remain cohesive and easier to evolve over time.

Key Principles

CRC cards embody the principle of single responsibility, which posits that each class should encapsulate a single, well-defined role to prevent functional bloat and promote maintainability. By listing responsibilities as concise verb phrases that identify specific problems to be solved, CRC cards ensure that classes remain focused and avoid unrelated duties, aligning with the idea that a class's primary purpose should be singular and cohesive. This approach, introduced by Beck and Cunningham, helps designers avoid overloading classes, fostering modular code where each class handles one aspect of the system's behavior. A core tenet emphasized in CRC cards is over , prioritizing message-passing interactions between classes rather than relying on hierarchical structures. Collaborators on a card name other classes that send or receive messages, highlighting inter-object service exchanges as the foundation of object-oriented systems. This principle, as articulated by and Cunningham, underscores that effective designs emerge from dynamic relationships and shared responsibilities, reducing the complexity often introduced by deep inheritance trees. CRC cards enforce low and high cohesion by encouraging minimal dependencies between classes while maximizing the internal focus of each class's responsibilities. Objects depend on collaborators only for necessary services, avoiding global control mechanisms and promoting loose interconnections that enhance flexibility and reusability. Responsibilities are kept tightly related within a class, with guidance to create new classes if cohesion wanes, thereby achieving designs where elements are highly interconnected internally but loosely so externally. This balance supports scalable object-oriented architectures, as noted in practices. The iterative discovery principle in CRC cards facilitates evolving designs through scenario-based exploration, allowing teams to refine classes by simulating interactions and uncovering emergent requirements. By walking through "what-if" scenarios, designers progress from known responsibilities to unknowns, iteratively adjusting collaborators and duties to validate and evolve the model. This process, central to the methodology's and application, enables of object behaviors without rigid upfront specifications.

History

Origins

Class-responsibility-collaboration (CRC) cards were invented in 1989 by and while working at , specifically as a teaching aid to help non-object-oriented programmers transition to object-oriented thinking. The technique emerged in response to the challenges of explaining how objects collaborate and interact in a system, providing a tangible way to explore these behaviors without writing code. Initially, CRC cards were implemented as a digital stack, which allowed for automatic indexing of collaborators, before evolving into physical 4x6-inch index cards for greater portability and independence from specific software systems. This shift enabled easier use in collaborative settings, where groups could manipulate the cards to simulate object interactions. The concept was first publicly described in a 1989 OOPSLA conference paper by and titled "A for Object-Oriented Thinking," where they introduced CRC cards as a tool to give learners direct experience with object technology. The early motivation behind CRC cards was to make object-oriented design more accessible, particularly by emphasizing the roles of classes and their interactions in small group exercises, bypassing the complexities of programming languages or formal diagrams. This approach aimed to immerse participants in the "object-ness" of systems, fostering intuitive understanding of collaborative behaviors among objects.

Development and Adoption

Following their initial proposal in 1989, CRC cards experienced significant expansion in the 1990s as and integrated them into (XP), an methodology they helped pioneer. This integration positioned CRC cards as a lightweight tool for collaborative design sessions, emphasizing rapid iteration and team-based exploration of object interactions. The technique gained widespread recognition through Beck's book Extreme Programming Explained: Embrace Change, which highlighted CRC cards' role in system restructuring and design refinement within XP practices. Adoption milestones in the late 1990s and early 2000s further solidified CRC cards' place in , particularly within agile methodologies where they supported mapping and emergent design. This alignment with pattern languages helped bridge informal brainstorming with structured design principles. Digital adaptations began emerging in the early 2000s, with tools like Excel Software's QuickCRC providing software-based representations of CRC cards to enable virtual collaboration and export to modeling formats. Some integrations with integrated development environments (IDEs) allowed for linking card-based designs to code generation, yet the practice's core strength in tactile, group maintained a preference for physical index cards in most professional and educational settings. The global spread of CRC cards accelerated by the mid-1990s, as they were incorporated into university curricula and industry training programs to teach object-oriented principles, with educators noting their effectiveness in fostering early design exploration. This adoption was intertwined with Ward Cunningham's broader contributions, including the 1995 invention of the as a platform for collaborative development.

Components of a CRC Card

Class Identification

The class identification section occupies the top portion of a CRC card, where the class name is prominently displayed for immediate recognition during design discussions. Typically, the name is written across the top or underlined in the upper-left corner of a standard 4x6-inch , ensuring it serves as the focal point of the card's content. Naming guidelines emphasize using concise, -based terms or phrases that evoke the class's essential role within the system's domain, such as "LibraryBook" to represent a borrowable item in a library system, rather than vague or overly generic labels. These names should be singular, capitalized, unambiguous, and consistent across the to build a shared among team members, avoiding abbreviations, digits, or terms that could confuse domain experts. An optional one-sentence may be placed on the back of the card to briefly clarify the class's scope and purpose, focusing on its high-level without delving into specifics—for instance, "Represents a physical available for circulation in the ." This description aids in distinguishing the class from others and reinforces its identity in collaborative settings. The importance of precise class identification lies in its role to uniquely define abstractions, prevent naming conflicts during group brainstorming sessions, and establish a foundation for assigning responsibilities, which describe the class's behaviors in response to messages from other objects.

Responsibilities

The responsibilities section occupies the left or central portion of a CRC card, immediately below the class name, and specifies the obligations of the class in terms of what it knows and does. This section is typically subdivided into two categories: "knows," which identifies the data, attributes, or information the class maintains (e.g., "knows account balance"), and "does," which describes the behaviors, methods, or actions the class performs (e.g., "dispenses cash"). These elements are phrased as concise, active verb statements to emphasize the class's external contracts rather than internal mechanisms. Guidelines for articulating responsibilities stress atomicity and simplicity, with each item listed as a bullet point representing a single, self-contained obligation. To prevent classes from becoming overly complex, the total number of responsibilities is limited to a small handful, often around 5 to 7, encouraging focused design and the potential decomposition into additional classes if exceeded. Action verbs are employed to make the phrases dynamic and precise, such as "calculate interest" or "validate input," while avoiding vague or speculative items unrelated to core requirements. Responsibilities fall into two types: simple ones that the class can fulfill independently through internal actions, like maintaining state or performing basic computations, and complex ones that inherently require external support, such as coordinating with other entities to complete a task. Private implementation details, such as specific algorithms or data structures, are deliberately omitted to keep the focus on abstract, observable behaviors and promote flexibility in realization. Complex responsibilities may briefly note potential collaborators on the card to highlight dependencies without detailing interactions. During the iterative design process, responsibilities evolve as teams explore use-case scenarios; initially broad items may be refined for clarity, split into smaller units, or reassigned if analysis reveals over-specification (too many duties for one class) or under-specification (missing obligations). This refinement ensures the responsibilities align with the overall , fostering a balanced distribution of concerns across classes.

Collaborators

The collaborators section of a Class-Responsibility-Collaboration (CRC) card occupies the right-hand side or column, where the names of other classes that the primary class interacts with are listed, typically as bullet points for clarity. This placement visually separates it from the class name at the top and the responsibilities on the left, emphasizing external relationships over internal duties. Guidelines for populating this section stress including only those classes essential for fulfilling the primary class's responsibilities, such as when it lacks necessary information or capabilities on its own. Collaborators reflect the directionality of interactions, with the primary class either requesting services (outgoing) or providing them (incoming), without delving into implementation details. In object-oriented design, this section serves to highlight interfaces and message flows between classes, revealing how responsibilities—such as or task delegation—necessitate external support without specifying communication protocols or methods. By focusing on these high-level interactions, collaborators promote a modular view of the system, where each class's dependencies are transparent yet concise, facilitating team discussions on cohesion and .

Process of Creation

Preparation and Brainstorming

The preparation phase for creating Class-Responsibility-Collaboration (CRC) cards begins with assembling a small, diverse team typically consisting of 3 to 6 participants, including 1-2 domain experts familiar with the system's requirements, 1-2 systems analysts, an experienced object-oriented designer, and a skilled in group dynamics and OO principles. This team size promotes collaborative discussion without overwhelming participation, ensuring all voices contribute equally to avoid dominance by any individual. Essential materials include physical index cards (preferably 3x5 or 4x6 inches for portability and tactile manipulation), markers for writing, and optionally refreshments to maintain an informal atmosphere; digital tools may supplement but should not replace the hands-on nature of cards. Prior to the session, the team defines the system domain by reviewing requirements documents, user stories, or high-level scenarios to establish a focused scope, such as an ATM withdrawal process or library checkout flow. Brainstorming follows immediately in a time-boxed session of 1 to 2 hours to generate momentum and prevent over-analysis, starting with the identification of candidate classes derived from the requirements. Participants scan the for nouns, pronouns, and s to propose initial class names, such as "Account" or "Deposit" in a banking , writing each on the upper-left corner of a card using a single, meaningful . Group discussion then ensues in a fast-paced, inclusive format—employing techniques like round-robin sharing where each member contributes ideas without interruption—to propose and jot down preliminary responsibilities as verb phrases on the card's left side, focusing on what the class "knows" or "does." This phase emphasizes equality of ideas, quick thinking, and humor to foster , with classes categorized temporarily as "winners," "losers," or "maybes" to filter and prioritize through consensus. To seed and validate these initial ideas, the brainstorming adopts a scenario-driven approach, beginning with a simple or high-level flow selected from the prepared requirements, such as "a customer withdraws cash from an ." Team members engage in verbal , with each person embodying a class (e.g., "I am the ; I need to collaborate with the to verify the PIN"), physically moving and waving cards to simulate interactions and reveal emergent responsibilities or collaborators. This tactile, low-tech environment—conducted in a flexible space allowing cards to be stacked, rearranged, or annotated on a table—enhances and communication, as the physical manipulation of cards mirrors the dynamic nature of object collaborations in the design. A designated scribe may note key scenarios or decisions to support later reference, ensuring the session remains focused on exploration rather than documentation.

Iteration and Refinement

Following the initial brainstorming phase, the iteration and refinement of CRC cards involve simulating system behavior through walkthroughs to test and adjust the . In a typical walkthrough, team members physically manipulate the cards on a table to represent object interactions, passing cards to one another to mimic in scenarios derived from use cases or requirements. This "acting out" process, often called , allows participants to assume the roles of classes, verbalizing responsibilities and identifying needed collaborations in real-time, which uncovers inconsistencies or missing elements early. Refinement rules guide adjustments to ensure the cards form a coherent model. Overloaded classes, where a single card accumulates too many responsibilities, are split into multiple cards to distribute duties more evenly and promote single-responsibility principles. Duplicate responsibilities across cards are merged to eliminate , while unnecessary collaborators are removed by reviewing interaction lists for . Gaps identified during simulations prompt updates, such as adding new responsibilities or collaborators, with cards rephrased for clarity and precision to avoid ambiguity in object behaviors. Validation during iteration focuses on achieving balance and completeness across the set of cards. Teams check that no class bears excessive responsibilities, ensuring each maintains a focused scope, and verify that scenarios can be executed without contradictions in message flows or unresolved dependencies. This process repeats through multiple cycles until the design covers key scenarios robustly, with spatial arrangement of cards on a surface aiding visualization of relationships and dependencies. The refined CRC cards are then compiled into a preliminary object model, often serving as a bridge to more formal artifacts like UML class diagrams or direct implementation in code. This transition preserves the low-fidelity insights gained from the cards while enabling further elaboration in development tools.

Applications

In Object-Oriented Design

Class-responsibility-collaboration (CRC) cards serve as a foundational tool in the object-oriented (OO) design phase, particularly within the analysis and early design stages of the lifecycle. They enable teams to model domain entities by identifying candidate classes, outlining their responsibilities, and mapping interactions with other classes, often preceding the creation of formal UML diagrams or implementation. This approach aligns with principles, where objects are viewed as performers of work, holders of information, or coordinators, allowing designers to explore and refine system structure iteratively without heavy reliance on tools. In OO design, CRC cards offer significant benefits by facilitating the discovery of classes through the examination of use cases and domain concepts, helping to pinpoint key abstractions and avoid premature details. They aid in defining interfaces by specifying responsibilities that form contracts between objects, while private responsibilities support internal logic, promoting encapsulation and . Additionally, CRC cards ensure polymorphism by emphasizing role-based behaviors, where classes can fulfill interchangeable roles through shared collaborations, enhancing design flexibility and reusability across the system. The typical workflow begins with requirements gathering, where scenarios are brainstormed to generate initial CRC cards listing classes, responsibilities, and . These cards are then simulated through or rearrangement to validate interactions, evolving into or diagrams that inform class diagrams. This process supports refactoring by allowing teams to revisit and adjust cards as new insights emerge, maintaining alignment with evolving requirements. In practice, CRC cards are commonly employed in small-to-medium projects for , where their low-tech, collaborative nature enables quick iterations and effective complexity management in team settings.

In Modern Methodologies

In agile methodologies, Class-Responsibility-Collaboration (CRC) cards serve as a lightweight, collaborative tool for emergent , particularly within (XP) practices. They align closely with by enabling two developers to simulate object interactions through scenarios, where one acts as a class and the other as its collaborator, fostering rapid identification of design flaws. This approach supports test-driven design by clarifying responsibilities before coding, ensuring that classes focus on behaviors that can be verified through tests. In XP sprints, CRC cards facilitate iterative refinement during short design sessions, allowing teams to evolve models incrementally without overcommitting to upfront architecture. Modern extensions of CRC cards incorporate digital formats to enhance accessibility in distributed teams. Tools such as provide templates for creating virtual CRC cards, where users can define classes, responsibilities, and collaborators in a shared workspace, supporting real-time editing and visualization of interactions to spot system weaknesses. Similarly, platforms like Miro and enable the use of digital for CRC modeling, promoting collaborative brainstorming akin to physical sessions but with added features like commenting and version history. In Scrum frameworks, CRC cards are often combined with user stories by modeling a single story's requirements on a set of cards, which helps teams translate high-level narratives into concrete class designs during sprint planning. Beyond traditional , CRC cards find application in (DDD) to delineate bounded contexts and aggregates. In DDD, cards model Aggregate Roots by outlining their responsibilities—such as enforcing business invariants—and collaborations with entities or value objects, ensuring consistent domain modeling within isolated contexts. This technique aids in grouping related domain elements, preventing overly coupled designs in complex systems. In educational settings, CRC cards are employed to teach architectures by having students create cards for service groups, simulating interactions to reveal issues like cyclic dependencies and reinforcing principles of . Groups typically work in small teams to produce and present cards, building consensus on service responsibilities. As of 2025, CRC cards maintain relevance in remote teams through virtual adaptations, such as web-based apps that replicate physical card manipulation for distributed collaboration, enabling agile design sessions without in-person proximity. Integration with AI-assisted tools further modernizes their use; for instance, platforms allow users to input textual descriptions of requirements, with AI auto-generating CRC card structures, including classes, responsibilities, and collaborators, while supporting natural language refinements for iterative adjustments. These enhancements streamline design for hybrid workflows, preserving the tool's emphasis on team dialogue.

Benefits and Limitations

Advantages

CRC cards offer simplicity and accessibility as a low-tech tool requiring only index cards, making them inexpensive, portable, and readily available without the need for specialized software or complex diagramming tools. This approach is particularly suitable for beginners and facilitates quick design sessions, as it leverages familiar materials to explore object-oriented concepts without . The technique promotes by encouraging group activities where members physically manipulate cards, role-play classes, and discuss scenarios, fostering shared understanding and incorporating diverse perspectives. Such interactive sessions ensure that designs are validated through and collective input, enhancing cohesion and uncovering potential issues early in the process. CRC cards emphasize essentials by directing focus toward high-level responsibilities—expressed as concise verb phrases—rather than detailed , which helps prevent over-engineering and maintains clarity in design. This structure forces conciseness, ensuring that attention remains on core problems to be solved and essential collaborations, thereby promoting robust and maintainable object-oriented models. Their flexibility allows for easy iteration, as cards can be rearranged, annotated, or discarded during brainstorming, supporting adaptive exploration from known to unknown elements in the . This makes them ideal for teaching object-oriented principles and scaling to large-group sessions, where rapid adjustments refine ideas without rigid commitments.

Drawbacks

While CRC cards offer a tactile and collaborative approach to object-oriented , their physical format imposes significant limitations, particularly for large systems where managing numerous cards becomes cumbersome and prone to disorganization. In such scenarios, the manual handling of extensive card sets hinders effective and scenario exploration, often leading to incomplete coverage of complex interactions or overlooked behaviors in large-scale use cases. This physical constraint makes CRC cards less effective for projects exceeding a moderate number of classes, as the effort required to track and rearrange cards grows disproportionately. The inherent informality of CRC cards presents challenges in documentation and integration with more structured modeling tools, such as UML, since they produce no digital artifacts and require manual transcription for formal representation. Without predefined templates for service details or clear role definitions, responsibilities may lack precision, complicating the transition to class diagrams and increasing the risk of errors during verification. This absence of standardization can result in low cohesion within classes and high coupling between them, as overloaded responsibilities fail to align with rigorous design principles. Subjectivity in CRC card development arises from their reliance on group consensus during brainstorming and role-play, which can introduce biases, ambiguities, or incomplete designs if participants misinterpret responsibilities or overlook relevant collaborators. For instance, the absence of explicit guidelines for defining roles often leads to extraneous or irrelevant assignments, exacerbated by difficulties in recalling states during dynamic sessions. Such consensus-driven processes risk "macho classes" that centralize excessive intelligence, undermining balanced object-oriented partitioning. CRC cards' physical nature can pose challenges in code-centric environments favoring digital tools, as manual updates for evolving designs—such as renaming classes or responsibilities mid-session—may be inefficient compared to electronic alternatives. However, digital variants in collaborative tools like virtual whiteboards address some of these issues by enabling scalable, persistent modeling as of 2025.

Examples

Basic Example

A basic example of CRC cards can be illustrated using a simple library management system, where users (members) borrow books, and the system tracks loans. In this scenario, key classes include "Book," "Member," and "Loan," which emerge from analyzing basic operations like checking out a book. Consider the "Book" class as a starting point. Its CRC card lists responsibilities such as recording checkout details (e.g., via an "issue" method to initiate borrowing) and updating status (e.g., marking as available or on loan after return). Collaborators include "Loan" (to manage the borrowing record) and "Member" (to verify borrower eligibility). These elements capture the book's role in the lending process without delving into implementation details. Visually, a CRC card is typically a 4x6-inch divided into sections: the class name ("") at the top, a brief or main responsibility below it, a bulleted list of doing responsibilities (e.g., "record checkout," "update status") and knowing responsibilities (e.g., "current status," "title") in the middle-left, and a bulleted list of collaborators (e.g., "," "Member") on the right. The back may note attributes like or due date. This layout facilitates quick sketching during team sessions, modeling simple interactions like a member requesting a book, where the Book object queries the Loan object for availability and collaborates with Member for . During brainstorming for the checkout scenario, teams often discover the need for a new "" class to handle transaction-specific data (e.g., borrow date, due date), separate from the Book's inherent properties, refining the model iteratively.

Advanced Example

In an advanced application of CRC cards, consider a point-of-sale (POS) system for a retail environment, where multiple classes interact to handle complex transactions involving inventory updates, payments, and error conditions. This builds on basic CRC modeling by simulating a full flow, such as scanning products, applying discounts, processing payments, and updating stock levels, demonstrating how cards evolve through . A key class in this system is the Register, which serves as the central coordinator for transactions. Its CRC card might list responsibilities such as "process sale by aggregating items," "handle payment initiation," "generate receipt upon completion," and "manage error conditions like insufficient inventory." Collaborators include Payment (for authorizing and recording funds), Inventory (for checking and updating stock), Product (for retrieving item details), and Receipt (for outputting transaction summaries). For instance, during a scenario simulation where a customer attempts to purchase an out-of-stock item, the Register card would reveal the need to query Inventory first, potentially triggering an "alert low stock" responsibility if levels fall below a threshold. To illustrate interactions, envision a sales flow: The Register initiates by collaborating with Product to add items (e.g., a SalesLineItem subclass or direct query for and description), then checks for availability. If a discount applies (e.g., for bulk buys), an initial set of cards might overlook this, leading to refinement by introducing a new Discount class with responsibilities like "calculate percentage off" and "validate eligibility," collaborating back with Register and Product. then handles authorization, possibly delegating to external services for validation, while deducts quantities post-successful payment. This role-playing uncovers dependencies, such as Register needing to rollback updates on payment failure, ensuring fault-tolerant . The Product card complements this with responsibilities like "provide description and price" and "check category for promotions," collaborating with Register and Inventory. Payment focuses on "authorize transaction," "record amount and method," and "handle refunds," partnering with Register and potentially external gateways. Inventory manages "update stock levels," "query availability," and "reorder if low," interacting with Register and Product. Through iterative simulation, these cards evolve from isolated definitions to a cohesive model, revealing emergent needs like a Discount class to modularize pricing logic and prevent Register overload. This process highlights CRC cards' scalability in complex systems, fostering refined object interactions without premature code commitment.

References

  1. https://c2.com/doc/oopsla89/paper.html
  2. https://agilemodeling.com/artifacts/crcmodel.htm
  3. https://dl.acm.org/doi/10.1145/74878.74879
  4. https://agilealliance.org/glossary/crc-cards/
  5. https://www.cs.unc.edu/~stotts/COMP145/CRC/crc.html
  6. https://www.researchgate.net/publication/242821918_CRC_cards_for_product_modelling
  7. http://bilalbajwa.pbworks.com/w/file/fetch/53054363/crcModeling.pdf
  8. https://worrydream.com/refs/Beck_1989_-_A_Laboratory_For_Teaching_Object-Oriented_Thinking.pdf
  9. http://www.cs.unc.edu/~stotts/COMP145/CRC/papers/beck.html
  10. https://www.methodsandtools.com/archive/archive.php?id=90
  11. https://homepages.inf.ed.ac.uk/perdita/OO/crc.pdf
  12. https://userpages.umbc.edu/~cseaman/ifsm636/lect1108.pdf
  13. https://c2.com/doc/firstcrc.pdf
  14. https://john.cs.olemiss.edu/~hcc/csci658/notes/UsingCRC.pdf
  15. https://static.aminer.org/pdf/PDF/000/589/681/role_playing_in_an_object_oriented_world.pdf
  16. https://cs.gordon.edu/courses/cps122/lectures-2016/Identifying%20Responsibilities;%20CRC%20Cards.pdf
  17. https://www.deltaexpertise.nl/images/4/4d/CRC-Intro.pdf
  18. https://www.launchnotes.com/glossary/crc-cards-in-product-management-and-operations
  19. https://www.geeksforgeeks.org/system-design/class-responsibility-collaboration-card/
  20. https://chisellabs.com/glossary/what-are-crc-cards/
  21. https://www.nyu.edu/classes/jcf/g22.2440-001_sp05/slides/session6/g22_2440_001_c62.pdf
  22. https://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf
  23. https://ptgmedia.pearsoncmg.com/imprint_downloads/informit/op/9780201379433_objectdesign.pdf
  24. https://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/chap03.pdf
  25. http://www.extremeprogramming.org/rules/crccards.html
  26. https://lucid.co/templates/crc-cards
  27. https://socadk.github.io/design-practice-repository/activities/DPR-TacticDDD.html
  28. https://technology.blog.gov.uk/2015/11/16/applying-the-concept-of-class-responsibility-cards-to-microservice-architectures/
  29. https://www.simplybusiness.co.uk/about-us/tech/2022/08/agile-software-design-with-crc-cards/
  30. https://www.chatdiagram.com/template/crc-cards-template
  31. https://wwwcgi.teach.cs.toronto.edu/~csc207h/winter/lectures/L0201/w5/CRC.pdf
  32. https://people.cs.pitt.edu/~chang/231/5spec/CRCcard/Biddle-Reflection.pdf
  33. https://www.st.uni-trier.de/diehl/pubs/crewspace_sac14_preprint.pdf
  34. https://www.researchgate.net/publication/4047722_A_pattern_for_an_effective_class_responsibility_collaborator_CRC_cards
  35. https://faculty.ksu.edu.sa/sites/default/files/ct1414_lecture5.pdf
  36. https://www.cs.mta.ac.il/msc/projects/Assaf_Raman/project.pdf
  37. https://www.cs.montana.edu/courses/fall2003/current/210/lectures/saveolduml/UML/Introduction.html
  38. https://www.oreilly.com/library/view/applying-uml-and/0130925691/
  39. https://www.oreilly.com/library/view/applying-uml-and/0130925691/0130925691_ch16lev1sec12.html
Add your contribution
Related Hubs
User Avatar
No comments yet.