Requirements

Let's design a chat application, think WhatsApp or WeChat, but simplified and focused on the core chatting functionality. We'll concentrate on the low-level design aspects: how to structure the classes, handle different message types, manage users, and ensure thread safety. We'll leave aside features like voice calls, video calls, stickers, and complex group management. The system should support one-on-one chats, group chats, and different message formats. The goal is to create a robust, extensible, and maintainable codebase that can form the foundation for a more feature-rich application. Think about how to add new message types (e.g., location sharing) without modifying existing core classes. How would you handle concurrent access to the chat history? This exercise isn't about building a distributed, scalable system for millions of users; it's about crafting a clean, well-designed, in-memory application. # Requirements ## Functional Requirements 1. **User Management:** * Users should be able to register with a unique username. * Users should be able to login. * The system should maintain a list of active users. 2. **One-on-One Chat:** * Users should be able to send text messages to other users. * Messages should be delivered to the recipient in the order they were sent. * The chat history should be persisted (in-memory for this exercise). 3. **Group Chat:** * Users should be able to create groups and add other users. * Users in a group should be able to send messages to the group. * Messages should be delivered to all group members in the order they were sent. * The chat history for each group should be persisted (in-memory for this exercise). 4. **Message Types:** * Support for plain text messages. * Support for image messages (store only a reference/path; actual image data handling is out of scope). * The system should be designed to easily support new message types in the future (e.g., location, video). 5. **Message Delivery Status:** * Track the status of a message (e.g., sent, delivered). We don't need "read" status for simplicity. 6. **Persistence:** * All messages and user data should be stored in-memory. For a production system, we'd use a database, but for this LLD exercise, in-memory persistence is sufficient. ## Non-Functional Requirements 1. **Thread Safety:** The application must be thread-safe to handle concurrent message sending and receiving from multiple users. Consider the implications of concurrent access to shared data structures like chat histories and user lists. 2. **Extensibility:** The system should be designed to easily accommodate new message types (e.g., video, location), new features (e.g., message editing, reactions), and new communication protocols (e.g., WebSockets). Avoid tight coupling and favor loose coupling. 3. **Modularity:** The system should be divided into well-defined modules with clear responsibilities. This will improve maintainability and testability. 4. **Testability:** The code should be designed to be easily testable. Use dependency injection and interfaces to facilitate unit testing. 5. **SOLID Principles:** Adhere to the SOLID principles of object-oriented design: * **Single Responsibility Principle:** Each class should have a single, well-defined responsibility. * **Open/Closed Principle:** Classes should be open for extension but closed for modification. * **Liskov Substitution Principle:** Subtypes should be substitutable for their base types. * **Interface Segregation Principle:** Clients should not be forced to depend on methods they do not use. * **Dependency Inversion Principle:** High-level modules should not depend on low-level modules. Both should depend on abstractions. 6. **Error Handling:** Implement robust error handling to prevent crashes and provide informative error messages. ## Core Entities 1. **User:** Represents a user in the system. Attributes: username, password (simplified for this exercise; in a real system, you'd hash and salt passwords), and potentially a unique user ID. Consider how to represent user status (online/offline). 2. **Message:** Represents a message sent between users or in a group. Attributes: sender, content, timestamp, message type (Text, Image, etc.), delivery status. Use inheritance or composition to handle different message types. 3. **Chat:** An abstract class or interface representing a conversation. It should have methods for sending messages and retrieving chat history. 4. **OneToOneChat:** A concrete implementation of `Chat` for one-on-one conversations. 5. **GroupChat:** A concrete implementation of `Chat` for group conversations. Attributes: group name, list of members. 6. **MessageFactory:** A factory class responsible for creating different types of messages. This allows for easy extension with new message types. This encapsulates the message creation logic and decouples it from the rest of the application. 7. **ChatService:** A service class that manages chats, users, and message delivery. It provides methods for creating chats, adding users to groups, sending messages, and retrieving chat history. This class acts as a central point of interaction for the chat functionality. 8. **DeliveryStatus:** Enum to represent the delivery status of a message (e.g., SENT, DELIVERED). This avoids using magic numbers or strings and makes the code more readable and maintainable.

Design Chat Based application like whatsapp/wechat.

Requirements

Think like an Architect

Premium Content