为接口添加hook方法获取实现类对象是否违反设计原则或属反模式？

Answer #

Great question—let’s unpack this approach, its tradeoffs, and whether it aligns with solid design principles.

First, the small upsides (可取之处) #

• This hook method solves your immediate problem cleanly for the current setup: you retain the ITest interface reference while accessing B's unique method2() without adding extra classes or objects.
• For a small, closed codebase where you don’t anticipate adding new ITest implementations, it feels like a low-effort, pragmatic workaround.

But this approach violates key design principles (and risks being an anti-pattern) #

Here’s why this isn’t a sustainable long-term solution:

1. Breaks the Dependency Inversion Principle
   Interfaces exist to act as abstract contracts, decoupled from concrete implementations. By adding B hook() to ITest, you’re making the interface depend on a specific class (B)—the exact opposite of what the principle prescribes. If you ever need to add another ITest implementation (e.g., C), this method becomes impossible to implement correctly without breaking type safety. The interface loses its purpose as a reusable abstraction.

2. Violates the Interface Segregation Principle
   Interfaces should only include methods that are relevant to all their clients. The hook() method isn’t part of the core ITest behavior—it’s a hack to access B's specific functionality. This forces every future ITest implementation to provide a hook() method, even if it’s irrelevant or impossible for them to do so.

3. Circumvents the core idea of "programming to an interface"
   The goal of using an interface reference is to depend on behavior, not implementation details. By calling test.hook().method2(), you’re still tightly coupling your client code to B—you’re just doing it indirectly. If B changes or you swap it for another ITest implementation, your code will break just as easily as if you’d used a B reference directly.

Better alternatives to consider #

• Add method2() to the ITest interface: If method2() is a behavior that all ITest implementations should support, this is the most straightforward, principle-aligned fix. It makes the contract explicit and keeps your client code clean.
• Use interface segregation: Split the behavior into smaller, focused interfaces. For example, create an IBExtra interface with method2(), then have B implement ITest, IBExtra. Clients that need method2() can depend on IBExtra, while others stick to ITest—this keeps interfaces lean and avoids forcing irrelevant methods on implementations.
• Use a B reference when appropriate: Programming to an interface isn’t a rigid rule. If your client code specifically needs to interact with B's unique behavior, there’s no shame in referencing B directly. The principle exists to reduce coupling when you need flexibility, not to force abstraction where it’s unnecessary.
• Visitor Pattern (for complex scenarios): If you have multiple ITest implementations with unique methods, the Visitor pattern lets you add operations without modifying the interface or implementations, keeping coupling low while supporting specific behaviors.

Final takeaway #

Your hook method is a clever short-term workaround, but it’s not a sustainable, principle-compliant design. It trades long-term maintainability for immediate convenience. For most production codebases, adjusting your interface design or dependency structure to align with SOLID principles will serve you better than relying on this approach.

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