From a128db1b6b3aca0feb713dc3f27928c660db2355 Mon Sep 17 00:00:00 2001 From: noQils <daffaaqilmahmud@gmail.com> Date: Thu, 27 Mar 2025 14:47:47 +0700 Subject: [PATCH] add Reflection Publisher-1 --- README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/README.md b/README.md index 3043f06..407a357 100644 --- a/README.md +++ b/README.md @@ -77,6 +77,17 @@ This is the place for you to write reflections: ### Mandatory (Publisher) Reflections #### Reflection Publisher-1 +## 1. Do we still need an interface (or trait in Rust) for the Subscriber in the BambangShop case? + +In the Observer design pattern, the `Subscriber` (or `Observer`) is typically an interface (trait in Rust) that allows different concrete implementations of subscribers to be notified when a state change occurs in the `Subject`. This abstraction enables flexibility, as multiple types of subscribers can exist with different behaviors. However, in the BambangShop case, if all subscribers share the same structure and behavior meaning they only store information and do not require different implementations then using a single `Subscriber` struct is sufficient, and a trait is unnecessary. If, in the future, different types of subscribers with distinct behaviors (e.g., logging subscribers, email subscribers, etc.) are needed, then defining a `Subscriber` trait would make sense. Otherwise, keeping it as a single struct simplifies the design without unnecessary abstraction. + +## 2. Is using `Vec` sufficient, or is `DashMap` necessary for unique `id` in `Program` and `url` in `Subscriber`? + +Using a `Vec` (list) would not be an efficient solution for ensuring uniqueness of `id` in `Program` and `url` in `Subscriber`, because checking for uniqueness in a `Vec` requires iterating through all elements, making insertions and lookups have a time complexity of `O(n)`. In contrast, `DashMap` (or a `HashMap` in a single-threaded context) provides constant-time `O(1)` average complexity for insertions and lookups, ensuring uniqueness efficiently. Since the requirement is to enforce unique `id` and `url`, a map-based structure like `DashMap` is necessary. Additionally, `DashMap` allows for concurrent read and write operations, making it more suitable in a multi-threaded environment where multiple threads may access or modify the subscriber list simultaneously. + +## 3. Do we still need `DashMap`, or can we use the Singleton pattern instead? + +The Singleton pattern ensures that only one instance of a structure exists throughout the program, which is useful for maintaining a global state, such as the `SUBSCRIBERS` list. However, in Rust, simply using the Singleton pattern with a `Mutex<HashMap>` or `RwLock<HashMap>` would introduce locking overhead, which can degrade performance when multiple threads try to read or write simultaneously. `DashMap` is designed to provide fine-grained locking, allowing multiple threads to access different parts of the map concurrently without blocking each other. This makes `DashMap` a more efficient and scalable solution for a globally shared, thread-safe `HashMap`. While the Singleton pattern could be used, it would require additional synchronization mechanisms, making `DashMap` the better choice for managing concurrent access to subscribers in a high-performance application. #### Reflection Publisher-2 -- GitLab