CPW-207 Assignment 2 Alex #27
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds CRC (Class-Responsibility-Collaborator) cards documentation for Assignment 2 of CPW-207. The document defines four classes involved in a messaging/chat system: Conversation, InterWebSocket, Message, and Notification (Inbox), along with their responsibilities and collaborators.
Changes:
- Added new CRC cards documentation file defining the design of a messaging system with four main classes and their interactions
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - InterWebSocket | ||
|
|
||
|
|
||
| ## InterWebSocket |
There was a problem hiding this comment.
The class name "InterWebSocket" doesn't match the actual implementation in the codebase. The codebase uses the standard "WebSocket" from the 'ws' library (see server.js line 8). Consider renaming this to "WebSocket" or "WebSocketHandler" to align with the actual implementation.
| - InterWebSocket | |
| ## InterWebSocket | |
| - WebSocket | |
| ## WebSocket |
|
|
||
| **Responsibilities** | ||
| - Updates users in real time when a message, letter, invite, etc. shows up. | ||
| - Updates player info in Online Multiplayer Games. |
There was a problem hiding this comment.
The responsibility "Updates player info in Online Multiplayer Games" appears to be out of scope for a WebSocket handler in a messaging/chat system. The actual WebSocket implementation in server.js focuses on handling chat messages, typing indicators, and read status updates (see lines 65-122 in server.js). Consider removing this responsibility or clarifying how it relates to the messaging system.
| - Updates player info in Online Multiplayer Games. | |
| - Handles real-time chat events such as typing indicators and read status updates. |
| **Collaborators** | ||
| - User | ||
| - Conversation | ||
| - Notification (Inbox) |
There was a problem hiding this comment.
The collaborator "Notification (Inbox)" references a class that doesn't have its own CRC card defined in this document. However, the codebase has a "Mail" table (DatabaseSetup.js lines 60-70) that appears to serve this purpose. Consider either adding a CRC card for Mail/Notification or removing this collaborator reference if it's not part of the messaging system being documented.
|
|
||
| **Responsibilities** | ||
| - Holds and receives messages sent by participants | ||
| - Keeps together replied messages and attachments |
There was a problem hiding this comment.
The responsibility "Keeps together replied messages and attachments" is ambiguous. Based on the database schema (DatabaseSetup.js lines 94-109), the ConversationData table stores messages with Reply references and Attachment fields. Consider rephrasing this to be more specific, such as "Maintains relationship between messages and their replies" or "Organizes message threads and attachments".
| - Keeps together replied messages and attachments | |
| - Maintains relationships between messages, their replies, and attachments |
| **Responsibilities** | ||
| - Holds and receives messages sent by participants | ||
| - Keeps together replied messages and attachments | ||
| - Informs users on which message the user last read. |
There was a problem hiding this comment.
The responsibility "Informs users on which message the user last read" is handled by a separate ConversationReadStatus table in the database (DatabaseSetup.js lines 111-124), not directly by the Conversation entity. Consider either moving this responsibility to a separate CRC card for read status tracking, or rephrasing it to indicate that Conversation coordinates with read status tracking rather than directly informing users.
| - Informs users on which message the user last read. | |
| - Coordinates with read status tracking to determine which message each user last read. |
| **Collaborators** | ||
| - User | ||
| - Conversation | ||
| - Friend No newline at end of file |
There was a problem hiding this comment.
"Friend" is listed as a collaborator but there is no corresponding CRC card for the Friend class in this document. The codebase has a Friends table (DatabaseSetup.js lines 72-81) and friend-related functionality. Consider adding a CRC card for the Friend class or explaining why it's referenced as a collaborator without its own card.
| - Friend | |
| - Friend | |
| ## Friend | |
| **Responsibilities** | |
| - Represents a friendship relationship between users | |
| - Stores friendship status and metadata (for example, when the friendship was created) | |
| - Supports friend-related actions such as sending and responding to friend requests | |
| **Collaborators** | |
| - User | |
| - Notification (Inbox) | |
| - Conversation |
| **Responsibilities** | ||
| - Contains information about what's in the message | ||
| - Tracks who sent it and when | ||
| - Holds possible rewards that can be obtained |
There was a problem hiding this comment.
The responsibility "Holds possible rewards that can be obtained" doesn't align with the Mail table implementation (DatabaseSetup.js lines 60-70), which has a "PackageContent" field but no specific "rewards" field. The codebase doesn't show any reward-handling logic in the mail/notification system. Consider clarifying this responsibility or verifying if rewards are actually part of the notification system design.
| - Holds possible rewards that can be obtained | |
| - Holds any associated package content or additional data |
| - InterWebSocket | ||
|
|
||
|
|
||
| ## InterWebSocket |
There was a problem hiding this comment.
The collaborator reference "InterWebSocket" should be updated to match the corrected naming convention. As noted in line 14, the actual implementation uses "WebSocket", not "InterWebSocket".
| - InterWebSocket | |
| ## InterWebSocket | |
| - WebSocket | |
| ## WebSocket |
My PR for CPW 207 Assignment 2: CRC Cards