A4 Redux SENG 301
Learning Objectives By now, you should have: Re-designed a system to make use of the façade design pattern Used event handling, and the observer design pattern to communicate between modules
“The Goal” Ostensibly: enabling extensibility Effectively: refactoring, and making some design choices
Refactoring to a layered architectural style Business Rule Funds or Payment Facade Product Facade Communication Facade Posted solution: Payment Façade listens for HardwareFacade.CoinSlot.CoinAccepted events Communication Façade listens for HardwareFacade.SelectionButton.Pressed events. When it gets these, the business rule is invoked Business rule checks price of item, checks if there’s enough credit; if there is, dispenses product, and then dispenses change Some of you didn’t use the events from C# and instead followed a more standard observer pattern. That’s fine. The C# approach is kind of like syntactic candy Hardware Facade
Ostensibly, what was difficult Certain “parts” can’t talk to one another This is annoying, and makes you wonder why “low coupling” is such a great ideaif everything can talk to everything else, wouldn’t that be better? This is why there was the “extensibility” argument: essentially, the idea is, “Think ahead! Later on, it’ll be a pain to change anything if it’s a big spaghetti mess!”
What was frustrating: Getting going “Where should X be?” “Should I do X or Y?” e.g. “Who should track the money in the system?”: Payment Façade or Business Rule? e.g. “Who should know how much a product costs?”: Product Façade or Payment Façade? These are valid questions, and no real great answers: there are trade-offs regardless of the choice you make
What was frustrating: the facades We provided you with the facades that were supposed to exist, and just said, “That’s the way it is going to be.” This was also problematic at times: e.g. “How is the communication façade supposed to communicate price of items (or ‘cost remaining’) if it doesn’t know how much a item costs?” The specific partitioning (i.e. the architecture) has certain deficiencies—other kinds of partitionings were possible
Wait, so how would I have added X? In principle, adding a new “payment” component (e.g. bill reader) would probably mean: (a) adding a new thing to the hardware façade, and then (b) adding a new thing to the Payment façade. (in both cases, likely fairly simple additions) Adding other I/O devices a little more complex. E.g. a touch screen (depending on what it shows) needs a bit more information—e.g. from product façade (pricing information), or from the payment façade (how much credit in system). This might mean that the partitioning doesn’t make sense, or that it is going to be a little more coupled than what we’d intended.
Learning Objectives Two layers of objectives. Layer 1: Layer 2: Refactor a system to make use of the façade design pattern, and layered architectural style Use event handling, and the observer design pattern to communicate between modules Layer 2: Face the challenge of dealing with having to design something with some uncertainty Recognize trade-offs between different designs