COMP 310/510 Fall 2013	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
  • ICmd2ModelAdapter interface
    • Available services
• IHost
  • 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?
• IChatRoom
  • No Add/RemoveAllUsers?
  • Lack of model access.
• IUser
  • Should one be able to get the IP address of an IUser?
• Using proxies/decorators to wrap stubs for easier equality testing and toString() behavior.
• Threading issues

© 2013 by Stephen Wong