COMP 310 Fall 2010	Lec35: Design Post-Mortem

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
• IConnection
  • alternatives?
• IChatRoom
  • No Add/RemoveAllUsers?
  • Returned type of sendMsg was an array, vs. an Iterable.
  • Lack of model access.
• IUser
  • getMsg return type, e.g. IStatus vs. ADataPacket
• IStatus
  • Inclusion of IUser sender.

Class Discussion Synopsis:

• Testing and debugging were hard.
  • Need a testing protocol beforehand.
• Understanding so many interfaces was hard
  • Hard to understand when interfaces were not all set.
  • The sheer volume of interfaces was hard to deal with.
  • Bottom line:  Need to research the interfaces early.
• Understanding the movement and usage of objects was hard
  • Which objects were serializable/stubs/etc.
  • Hard to understand where each object was physically located.
• Difficult to understand what responsibilities any object has
  • Sometimes some things were programmed in the wrong place
  • Problem compounded b unsettled or wrong API's.
• Threading and new technologies in general are hard
  • Just simply understanding what is going on
• Time management is hard
  • Most projects fail due to poor management than for any other reason.
• Extended Visitors
  • Easy to code since it was a pre-built library
  • Alternative:  un-encapsulate the visitor and worked with the command dispatching directly ==> but by the time one encapsulates the necessary operations, you're back to a visitor anyway.
  • The extended visitor had clear semantics on how it was being used.
• ICmd2ModelAdapter
  • Too restrictive.   Needs more flexibility
• IChatRoom
  • Add/RemoveAll:  whether to include or not involved questions of separation of responsibilities vs. the potential abuse of responsibilities.
  • The methods of IChatRoom were perhaps insufficiently well-defined?
  • The design choices of whether to include Add/RemoveAll and whether or not the chat room had access to the model/view were coupled together --> design choices can be coupled.

© 2010 by Stephen Wong and Scott Rixner