the bridge design pattern was used in M4, in cleaning up a design issue in M2. i used it to create a heirarchy of shapes, with each shape object inheiriting properties relevant to the program. the problem arose when it became difficult to have the shape objects be children of morph...so instead, each shape had a has-a link to a morph object, and a bridge was created to have the shape object i was using in the program interact and recieve the data from the morph object being shown on the screen.
in M4, the state design pattern was used to again clean up a design issue in M2. in the previous milestone, state was a string in the drawing editor class, and a case-statement style evaluation of state called the appropriate subroutine from inside drawing editor. it ended up better to create state objects, with the methods pertinent to the state within the state itself. this allowed for more flexibility and more mantainable code. i also coupled the states with an event handler, so on a mousedown, no longer did it depend on the state inside of drawing editor; the event became a set of interactions among the objects in the model. alan fay |
