I’m studying design patterns for an exam and I’m stuck on a question:
Combining the Separated Interface and Remote Facade patterns.
The textbook we’re using is “Patterns of Enterprise Application Architecture” (PEAA) by Martin Fowler [1]. Do you have any concrete examples of how these patterns can be combined in a real system?
I would appreciate any advice or references to specific examples in the PEAA book [1] that could help me better understand this combination.
ChatGPT gave me this answer, but I’m not sure what you think, it doesn’t quite convince me:
- Order management system: A web client needs to send an order to an order management system. The backend system is complex, with different modules for inventory, payment management, and database.
- Application:
- Separated Interface defines a remote interface with operations like createOrder , getOrder , and cancelOrder .
- Remote Facade implements this interface, receiving requests from the web client and delegating them to the backend modules.
- The web client only needs to know the remote interface, without needing to interact directly with the complex backend.
The exam restrictions are:
- Do not answer with what the book says.
- Understand the intent when responding.
According to my professor, remote facade doesn’t necessarily mean network communication to a server, as a process calling other processes, even if on the same machine, would still qualify.
2
Do you think you understand what the Remote Facade and Separated Interface patterns are all about?
Remote Facade is about making interactions less “Chatty” – on the assumption that:
- At design-time, having lots of fine-grain calls between components makes them more tightly-coupled, which is generally to be avoided.
- At runtime, each call introduces some kind of latency into the overall processing.
Separated Interface is basically loose-coupling through use of code-level interfaces (think “contract”) rather than against concrete classes or components (like Customer and Order as shown in the PEAA book). Many design patterns and architectural styles make heavy use of this idea – do a search on “Dependency Injection” and “Inversion of Control” and you’ll see how widespread this is. “Clean” architect is one of several architectural styles that use this concept.
The point of the question is probably to make sure you understand the ideas behind cohesion vs coupling; why tight-coupling is usually best avoid; and to think about how classes and components interact – both at design-time (affecting qualities like maintainability) and runtime (qualities like performance). Because both of these patterns (and the ideas behind them) are fairly central to good software design and architecture.