John Hofman's Design Study
John Hofman (Talk | contribs) |
John Hofman (Talk | contribs) |
||
| Line 21: | Line 21: | ||
UML | UML | ||
| + | |||
===Discussion of Initial Design=== | ===Discussion of Initial Design=== | ||
| − | + | Following the [[Do the simplest thing that could possibly work]] heuristic, the first design is better. The "Room for Conversation" design [[Model the real world|models the real world]] but a room with people is not necessarily what needs to be modelled. Therefore the second design is going to be discarded. | |
Improvements and Considerations | Improvements and Considerations | ||
| − | * The design is | + | * The design is dependent on the GUI library. Both Chat and UserManager dependant on the fltk library. Its not extensible. |
| + | ** The [[Bridge]] design pattern could be used to separate the interface and implementation of the UI. | ||
| + | ** The [[Abstract Factory]] could be used to increase exstensibility. | ||
| + | * The Gateway is tightly coupled with the UserManager and the Chat classes. The interaction between them is bi-directional. | ||
| + | **This coupling could be reduced by using [[Double dispatch]], but, this is a code smell that implies that [[Open closed principal]] or [[Single responsibility principal]]s are not being followed. | ||
| + | * The Gateway is currently responsible for connecting, sending and receiving information. Se | ||
| + | |||
Revision as of 21:59, 2 August 2010
Contents |
My Project
This design study was introduced by my ENEL428 software assignment. The purpose of the assignment is to design a prototype of an Instant Messenger System using concurrent programming. The system is broken into two separate parts a client and a server. This design study is for the client program.
The communication protocol was not specified so I am using a system similar to IRC where logging on only requires a unique username, not a user account. This means that the server only needs to maintain a list of currently online users.
Design Study
Initial Design
When I first sat down and started to think about how to divide up an instant messenger client into separate parts, I came up with two different abstractions of the client environment.
Chats
This design follows how existing instant messengers appear to present the clients structure. The user interface is used to manipulate chats. Chats communicate with the server to update chats in other clients.
UML
Room for Conversation
This design of the instant messenger client models a group of people conversing in a room. The model contains users objects, one for each person who is online. The users can interact through chats.
Users can create, join, leave and post messages to a chat. There is one user, the 'Home' user, that represents the person who is using the client program, the HomeUser is controlled by the user interface. The other users, OnlineUsers, are controlled by the network. However, the behavior of these 'online users' originated from the user input on their own client program somewhere else on the network. Therefore, whenever the HomeUser interacts with the chats, any actions it makes are also sent to the network connection to update the OnlineUser (kind of puppet) that represents it, in the other peoples client environment.
UML
Discussion of Initial Design
Following the Do the simplest thing that could possibly work heuristic, the first design is better. The "Room for Conversation" design models the real world but a room with people is not necessarily what needs to be modelled. Therefore the second design is going to be discarded.
Improvements and Considerations
- The design is dependent on the GUI library. Both Chat and UserManager dependant on the fltk library. Its not extensible.
- The Bridge design pattern could be used to separate the interface and implementation of the UI.
- The Abstract Factory could be used to increase exstensibility.
- The Gateway is tightly coupled with the UserManager and the Chat classes. The interaction between them is bi-directional.
- This coupling could be reduced by using Double dispatch, but, this is a code smell that implies that Open closed principal or Single responsibility principals are not being followed.
- The Gateway is currently responsible for connecting, sending and receiving information. Se
