Software Engineering and Architecture Pattern Catalog Facade New


![[Demo] • Run it CS@AU • Review GUI code Henrik Bærbak Christensen 3 [Demo] • Run it CS@AU • Review GUI code Henrik Bærbak Christensen 3](https://slidetodoc.com/presentation_image_h2/4bf3cf16a65ad1f889e75deb8b789b59/image-3.jpg)







- Slides: 10

Software Engineering and Architecture Pattern Catalog: Facade

New Requirement • It would be nice with a simple GUI “to see something” instead of just x. Unit tests. . . “The GUI History of Pay. Station” CS@AU Henrik Bærbak Christensen 2
![Demo Run it CSAU Review GUI code Henrik Bærbak Christensen 3 [Demo] • Run it CS@AU • Review GUI code Henrik Bærbak Christensen 3](https://slidetodoc.com/presentation_image_h2/4bf3cf16a65ad1f889e75deb8b789b59/image-3.jpg)
[Demo] • Run it CS@AU • Review GUI code Henrik Bærbak Christensen 3

Analysis • Seq Diagram – No difference in behavior of a GUI versus real hardware! CS@AU Henrik Bærbak Christensen 4

Conclusion • Any kind of user interface can operate the Pay. Station! • Wow – Change by addition. . . • How come we are so lucky? CS@AU Henrik Bærbak Christensen 5

Design considerations • (3) Behavior that may vary – the same hardware (or GUI) must operate varying pay station implementations: Alpha. Town, Beta. Town, Epsilon. Town. . . • (1) Variable behavior behind interface – Pay. Station interface. . . • (2) Compose behavior by delegation – Gui/Hardware does not itself calculate rates, issue receipts, etc. , but lets an instance of Pay. Station do the dirty job. . . CS@AU Henrik Bærbak Christensen 6

Result • The side effect of this decision is that interface decouples both ways!!! – Hardware may operate different kinds of Pay. Station implementations • Alpha, Beta, Gamma, … – Different kinds of user interfaces may operate the same Pay. Station implementation <<interface>> Pay. Station CS@AU * * Henrik Bærbak Christensen <<interface>> Pay. Station. GUI 7

Automagical pattern? • Pay. Station is an example of the Facade pattern C CS@AU Henrik Bærbak Christensen 8

Consequences • Benefits – Shields clients from subsystem objects • (depends… Consider Hot. Civ) – Weak coupling • Many to many relation between client and façade • Liabilities – Bloated interface with lots of methods • Because façade must have the sum of responsibilities of the subsystem – How to avoid access to the inner objects? • Read-only interfaces; no access (require dumb data objects to be passed and parsed over the facade). CS@AU Henrik Bærbak Christensen 9

Facade Variants • Facade appears on all levels of architecture – An Java Interface is a ‘small scale’ Facade… – The Layered architectural style defines a set of Facades – At remote service level, we have API Gateway CS@AU Henrik Bærbak Christensen 10