Conversation History Refactoring - Design Patterns

[milkdromeda]

• Observer

  • Usage: The view can observe the viewmodel for the use cases of sending a message and displaying the conversation history. The viewmodel contains the information to be displayed to the view -- this information will be constantly updated by the presenter. When this happens, the view will updated as well as it is observing the viewmodel.

• Builder

  • Usage: This design pattern can extend the current factory design pattern used for creating messages, allowing the construction of more complex messages.
  • A specific usage is the following: I am considering adding a message that requires a reply by a certain time. (These kind of messages might be useful for important announcements and getting feedback from participants in a chat in a timely fashion.) It might store additional parameters that are not needed by other message types, such as a LocalDateTime of when a response is expected and a boolean of whether a user has responded to the message. The issue here is that a message factory will take in a long list of parameters (many of which will not be used). To address this, I can introduce a builder class with methods that will initialize one parameter (e.g. whether a user has responded). For a certain message type, I can then build a message one step at a time without having to use all the steps.