COMP 310
Fall 2017
|
Lec35: Design
Almost Post-Mortem
|
|
Outstanding design issues:
-
What should be the type of the input parameter to the data packet
execute()
method, which is also the input parameter type for the data packet visitor's
caseAt() method and its commands'
apply() methods?
-
Implemenation Issues:
- Adding yourself to a chat room safely -- don't want to receive your own
IAddUser packet!
- How to insure that the processing of a datapacket has completed for all
users.
Let's spend today's lecture hour dissecting the ChatApp design for both its
strengths and weaknesses:
The Hardest Parts:
- Hardest to design?
- Hardest to understand?
- Hardest to code?
- Hardest to debug?
Issues to consider
- How did the design decision affect the program as a whole?
- Was it a positive or negative impact?
- Did it make the system simpler or more complex?
- Did it make coding easier or harder?
- Were you coding with or against the paradigm, i.e. did it help or
hinder your ability to express your ideas?
- Did it make the system more/less
- flexible
- extensible
- robust
- correct
- What were the alternatives?
- Overall, was it the right decision?
- What were the compromises?
Starting Points for Discussion:
- Use of extended visitors
- Overall effect on system
- For datapackets
- For status
- Command to local system interface
- Initial Connnection:
- How can one invite someone in a chat room whose computer you have
never contacted directly nor have they contacted you directly, i.e. you
don't have their IHost stub yet?
- Should you be able to get the IP address on an
IHost?
- Chat room
- No Add/RemoveAllUsers?
- Public interface or local implementation (i.e. only user list is
passed around)?
- Message receiver object
- Should one be able to get the IP address of a user?
- Using proxies/decorators to wrap stubs for easier equality testing and
toString() behavior.
- Threading issues
© 2017 by Stephen Wong