- Reflection Publisher-1
- 1. In the Observer pattern diagram explained by the Head First Design Pattern book, Subscriber is defined as an interface. Explain based on your understanding of Observer design patterns, do we still need an interface (or trait in Rust) in this BambangShop case, or a single Model struct is enough?
- 2. id in Program and url in Subscriber is intended to be unique. Explain based on your understanding, is using Vec (list) sufficient or using DashMap (map/dictionary) like we currently use is necessary for this case?
- 3. When programming using Rust, we are enforced by rigorous compiler constraints to make a thread-safe program. In the case of the List of Subscribers (SUBSCRIBERS) static variable, we used the DashMap external library for thread safe HashMap. Explain based on your understanding of design patterns, do we still need DashMap or we can implement Singleton pattern instead?
- Reflection Publisher-2
- 1. In the Model-View Controller (MVC) compound pattern, there is no “Service” and “Repository”. Model in MVC covers both data storage and business logic. Explain based on your understanding of design principles, why we need to separate “Service” and “Repository” from a Model?
- 2. What happens if we only use the Model? Explain your imagination on how the interactions between each model (Program, Subscriber, Notification) affect the code complexity for each model?
- 3. Have you explored more about Postman? Tell us how this tool helps you to test your current work. You might want to also list which features in Postman you are interested in or feel like it is helpful to help your Group Project or any of your future software engineering projects.
- Reflection Publisher-3
- 1. Observer Pattern has two variations: Push model (publisher pushes data to subscribers) and Pull model (subscribers pull data from publisher). In this tutorial case, which variation of Observer Pattern that we use?
- 2. What are the advantages and disadvantages of using the other variation of Observer Pattern for this tutorial case? (example: if you answer Q1 with Push, then imagine if we used Pull)
- 3.Explain what will happen to the program if we decide to not use multi-threading in the notification process.
Reflection Publisher-1
1. In the Observer pattern diagram explained by the Head First Design Pattern book, Subscriber is defined as an interface. Explain based on your understanding of Observer design patterns, do we still need an interface (or trait in Rust) in this BambangShop case, or a single Model struct is enough?
Tujuan Subscriber didefinisikan sebagai interface adalah untuk mendukung banyak implementasi dari observer. Hal ini juga memastikan bahwa setiap observer dapat dinotify secara seragam oleh publisher tanpa perlu mengetahui jenis spesifik dari observer.
Pada kasus bambangshop, tergantung tujuan apakah kita berniat menambah observer selai User di masa yang akan datang. Jika iya, alangkah baiknya kita tetap menggunakan interface/trait supaya memungkinkan kita menambah observer selain User di masa depan. Tetapi jika tidak, tidak perlu menggunakan interface/trait karena akan membuat struktur kode justru menjadi lebih kompleks.
2. id in Program and url in Subscriber is intended to be unique. Explain based on your understanding, is using Vec (list) sufficient or using DashMap (map/dictionary) like we currently use is necessary for this case?
Kita bisa saja menggunakan Vec (list) untuk kasus ini. Namun, drawback terbesarnya ada pada kompleksitas waktunya. Jika kita hanya menggunakan Vect (list), kita tidak bisa secara langsung memverifikasi keunikan id dan url yang sedang diinsert. Sehingga butuh looping untuk mengecek satu persatu elemen yang memakan waktu O(N). Sedangkan dengan DashMap ( What a cute name :> ), kita dapat melakukan hal tersebut dengan kompleksitas rata-rata O(1) karena kita dapat langsung mengetahui apakah index yg digenerate oleh hash sudah ditempati atau belum.
3. When programming using Rust, we are enforced by rigorous compiler constraints to make a thread-safe program. In the case of the List of Subscribers (SUBSCRIBERS) static variable, we used the DashMap external library for thread safe HashMap. Explain based on your understanding of design patterns, do we still need DashMap or we can implement Singleton pattern instead?
Kita tidak perlu menggunakan Singleton Pattern. Pada kasus ini, yang mana konkurensi diperhatikan, DashMap lebih baik dibanding dengan kita menggunakan Singleton Pattern. Hal ini karena DashMap sudah menyediakan thread safety tanpa memerlukan manual locking sehingga secara mudah memungkinkan thread untuk melakuakn r/w secara paralel dengan kompleksitas O(1). Sedangkan jika kita membuat Singleton dengan Mutex, setiap operasi r/w mengunci HashMap sehingga HashMap tidak dapat diakses thread lain ketika sedang dilakukan operasi.
Reflection Publisher-2
1. In the Model-View Controller (MVC) compound pattern, there is no “Service” and “Repository”. Model in MVC covers both data storage and business logic. Explain based on your understanding of design principles, why we need to separate “Service” and “Repository” from a Model?
Dengan membebankan tugas repository dan service hanya pda Model, projek menjadi lebih sulit dimaintain. Dengan adanya pemisahan tugas ini, repository berperan menghandle storage dan service menghandle logika bisnis, kedua beban tersebut menjadi independen sehingga ketika kita ingin memperluas salah satunya, kita tidak perlu menghiraukan yang lain.
2. What happens if we only use the Model? Explain your imagination on how the interactions between each model (Program, Subscriber, Notification) affect the code complexity for each model?
Model menjadi sangat bloated. Selain itu, skalabilitas menjadi sangat buruk, misal kita ingin mengubah cara notifikasi dikirim, kita perlu merubah model dibandingkan dengan mengubah hanya NotificationService.
3. Have you explored more about Postman? Tell us how this tool helps you to test your current work. You might want to also list which features in Postman you are interested in or feel like it is helpful to help your Group Project or any of your future software engineering projects.
Postman membantu kita untuk mengetest endpoint yang telah kita buat. Alih-alih memerlukan browser client seperti metode konvensional. Kita dapat menembak langsung ke endpoint dengan berbagai request method tanpa perlu berinteraksi melalui client. Hal ini sangat membantu kita dalam mengembangkan sisi backend dari sebuah aplikasi.
Reflection Publisher-3
1. Observer Pattern has two variations: Push model (publisher pushes data to subscribers) and Pull model (subscribers pull data from publisher). In this tutorial case, which variation of Observer Pattern that we use?
Kita menggunakan Push model pada projek ini, terlihat bahwa notifier tidak hanya menotify subscriber tetapi juga melakukan update langsung.
2. What are the advantages and disadvantages of using the other variation of Observer Pattern for this tutorial case? (example: if you answer Q1 with Push, then imagine if we used Pull)
Jika kita menggunakan Pull model pada tutorial ini, keuntungannya adalah observer dapat memutuskan sendiri berapa data yang diperlukan. Sedangkan kekurangannya adalah meningkatkan kompleksitas karena tiap observer harus melakukan fetch data sendiri-sendiri.
3.Explain what will happen to the program if we decide to not use multi-threading in the notification process.
Observer akan memiliki delay pada penerimaan notifikasi karena perlu menunggu pengiriman notifikasi untuk observer lain akan selesai. Bayangkan jika ada jutaan observer, maka proses akan menjadi sangat lama.