Abstract Factory Implementor

When to Use

You are creating families of related objects and the client must stay independent of which concrete family it uses. This skill applies under four specific conditions — all are sufficient; any one justifies the pattern:

1. Product-creation independence — a system should not depend on how its products are created, composed, or represented. Clients should work against abstract interfaces, not constructor calls.
2. Multiple product families — the system must be configured with one of several families of products (e.g., Motif widgets vs. Presentation Manager widgets vs. Mac widgets), and the choice of family should be a single point of configuration, not scattered throughout the codebase.
3. Enforced co-usage — products within a family are designed to work together, and you need a structural guarantee that clients never mix products from different families (a MotifScrollBar with a PMButton, for instance, is a violation the pattern makes structurally impossible).
4. Interface-only library — you are providing a class library and want to reveal only interfaces, not implementations. Clients code against the abstract factory and abstract product classes; the concrete implementations are deployment-time choices.

Before starting, confirm this is not a simpler case:

• If only one product type varies, prefer Factory Method — Abstract Factory is for families of products that must vary together.
• If the products are not related (no co-usage constraint), the coordination overhead of Abstract Factory is not justified.

Process