Requirements

Imagine you're building a Maps Navigator client that can provide directions and navigation information for various transportation types: driving, walking, cycling, and public transport. Each transportation type has its own specific routing logic and data requirements (e.g., driving needs road information, public transport needs schedules). The system needs to be extensible to support new transportation types in the future without modifying existing code extensively. Furthermore, certain navigation steps (like recalculating route) need to be done concurrently to avoid blocking the main thread. The existing client has some issues with tight coupling between the navigation logic and the UI, making it difficult to test and maintain. We need a robust and well-designed solution addressing these issues. # Requirements ## Functional Requirements 1. **Route Calculation:** * The system must be able to calculate a route between two given points (origin and destination) for a specified transportation type. * Support driving, walking, cycling, and public transport initially. * Each transportation type should use its specific routing algorithm (e.g., A\* for driving, Dijkstra for walking). * Consider real-time traffic data for driving routes and public transport schedules for public transport routes. Simulate this using stubbed methods for demonstration. * The system should provide estimated time of arrival (ETA) and distance for the calculated route. * The client should be able to provide multiple route options (e.g., fastest, shortest, least crowded). 2. **Navigation:** * The system must be able to provide turn-by-turn navigation instructions for the calculated route. * Instructions should be context-aware (e.g., "Turn left in 100 meters"). * The system should be able to handle deviations from the calculated route (re-routing). * Navigation should support real-time updates, such as traffic changes, road closures, and public transport delays. (Simulate this) * The system should display a map showing the current location, route, and upcoming instructions. (This will be a stub, focus on data and routing logic) * Provide audible navigation instructions. (This will be a stub). 3. **Transportation Type Management:** * The system should allow adding new transportation types easily without modifying core navigation logic. * Each transportation type should be responsible for its own routing algorithm and data retrieval. * The system should handle configuration for each transport type, such as API keys for public transport or preferred cycling routes. (Simulate this through configuration files/objects). 4. **Error Handling:** * The system should handle errors gracefully, such as invalid input, network connectivity issues, and routing algorithm failures. * Provide informative error messages to the user. * Implement retry mechanisms for transient errors. ## Non-Functional Requirements 1. **Extensibility:** The system should be easily extensible to support new transportation types and routing algorithms without requiring major code changes. Use design patterns to facilitate this. 2. **Modularity:** The system should be divided into independent modules with well-defined interfaces. This will improve maintainability and testability. 3. **Testability:** Each module should be testable in isolation. Aim for high code coverage with unit tests. 4. **Thread Safety:** The navigation and route recalculation logic should be thread-safe. Multiple requests might come in concurrently (e.g., re-routing while displaying current location). Implement appropriate synchronization mechanisms to avoid race conditions and data corruption. Consider immutable data structures where applicable to simplify concurrency. 5. **Performance:** The routing algorithm should be efficient enough to provide results in a reasonable time. Consider caching route data to improve performance. 6. **Maintainability:** The code should be well-documented and easy to understand. Follow SOLID principles. 7. **Separation of Concerns:** Separate the routing logic from the UI/presentation layer. Use appropriate architectural patterns (e.g., Model-View-Controller or similar) to achieve this. ## Core Entities 1. **`Navigator`:** The main entry point for navigation. It orchestrates the routing and navigation process. It is responsible for selecting the appropriate `TransportationMode` and initiating route calculation. 2. **`TransportationMode` (Interface):** An interface that defines the common operations for all transportation types (e.g., `calculateRoute`, `getNavigationInstructions`). Concrete implementations would be `DrivingMode`, `WalkingMode`, `CyclingMode`, and `PublicTransportMode`. This is core to the Strategy Pattern. 3. **`Route`:** Represents a calculated route, containing information like distance, ETA, and a list of `NavigationInstruction` objects. 4. **`NavigationInstruction`:** Represents a single step in the route (e.g., "Turn left on Main Street"). 5. **`RoutingAlgorithm` (Interface):** An interface for different routing algorithms. Implementations could be `AStarRoutingAlgorithm`, `DijkstraRoutingAlgorithm`. Could be used if the transportation mode does not tightly specify which algorithm to use. 6. **`MapDataService` (Interface):** An interface for accessing map data, like road networks, public transport schedules. Implementations could be `RoadNetworkService`, `PublicTransportScheduleService`. This allows abstraction from external APIs. 7. **`RouteRecalculator`:** A class responsible for recalculating the route when deviations occur. This will need to be thread-safe. 8. **`Configuration`:** A class to hold the overall configuration of the navigator, including API keys and transport-specific configurations.

Design Maps Navigator Client for different transportation types

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content