OOD层级结构接口转换及Facade设计模式扩展问题问询

Hey there! Since you're working through Design Patterns: Elements of Reusable Object-Oriented Software (such a foundational book—love that you're diving deep!), let's tackle your two questions about Facade and OOD interface practices:

1. How to transform interfaces in a hierarchical structure in OOD? #

When dealing with layered/hierarchical systems (think UI layer → business layer → data access layer, for example), interface transformation is all about bridging mismatches between what upper layers need and what lower layers expose—and the Facade pattern is perfect for this, often paired with other patterns like Adapter if needed.

Here's a practical breakdown:

• Simplify granularity: Lower-level subsystems typically have fine-grained, specialized interfaces (e.g., UserRepository.fetchById(), OrderRepository.fetchForUser()). A Facade can wrap these into a single, coarse-grained interface that upper layers find intuitive, like UserServiceFacade.getUserWithOrders(userId)—this transforms multiple low-level calls into one easy-to-use method.
• Adapt incompatible interfaces: If a lower layer's interface doesn't align with upper-layer expectations (e.g., different parameter formats, return types), you can use an Adapter inside the Facade. For example, if your data layer returns a raw SQL result set but your business layer needs a User object, the Facade can use a ResultSetToUserAdapter to convert the interface seamlessly without exposing the mismatch to upper layers.
• Hide hierarchical complexity: The key goal here is to decouple layers—upper layers don't need to know about the lower layer's structure or interfaces. The Facade acts as a single entry point, handling all the interface translation and coordination between layers.

2. If the Domain subsystem (used as a Facade/interface's subsystem) needs new features, do we have to modify the Domain class? #

Short answer: Not necessarily—if you've designed your system to follow the Open/Closed Principle (a core OOD principle highlighted in the book), you can extend functionality without modifying existing code.

Here's how to approach it:

• Extend the Facade, don't modify existing methods: If the Domain subsystem adds a new feature (e.g., a new generateInvoice() method), you can add a corresponding generateUserInvoice(userId) method to your Facade. This way, you're extending the Facade's interface without breaking existing code that relies on its original methods.
• Depend on abstractions, not concretions: If your Facade depends on an abstract interface for the Domain subsystem (e.g., IDomainService) instead of a concrete Domain class, you can create a new implementation of IDomainService that includes the new feature. Then, update your dependency injection (or initialization) to use the new implementation—no changes needed to the Facade itself.
• When you might need to modify the Facade: If the new feature requires changing the core logic of an existing Facade method (e.g., updating processOrder() to include a new validation step), you'll have to modify the Facade—but even here, try to minimize changes. For example, extract the new logic into a separate helper class or method so you're only adding code, not rewriting existing functionality.

Remember, the Facade pattern's job is to shield clients from subsystem complexity—so any changes should preserve that simplicity while allowing for extension.

内容的提问来源于stack exchange，提问作者Luai Ghunim