Factory Pattern.

Hook: The Factory Pattern is like ordering at a café: you ask for a drink, and the kitchen decides how to build it.

Question: What is the Factory Pattern in Java?

Answer: The Factory Pattern is a creational design pattern that hides object creation behind a method or class. Instead of calling new everywhere, your code asks a factory for an object and depends on an interface or base class, not a concrete class. That keeps creation rules in one place and makes the code easier to change and test.

Interview-Ready Answer: I use the Factory Pattern when I want to separate object creation from object usage. In Java, that usually means I call something like NotificationFactory.create(type) and get back an interface such as Notification, so the caller does not need to know which concrete class was built. The big win is flexibility: if I add a new product type later, I change the factory in one place instead of scattering new across the codebase.

Detailed Explanation:

What it is

The factory pattern is a way to put object creation behind a clean API. The caller says what it wants, and the factory decides which concrete class to build. In Java interviews, people often use the phrase factory pattern loosely, but the formal Gang of Four patterns are Factory Method and Abstract Factory. A simple static factory is also very common in real Java code.

How it works under the hood

1. The caller asks for a product using a simple name or configuration value, such as email or sms.
2. The factory normalizes the input and validates it. This is where you catch bad data early instead of returning null and letting a later NullPointerException happen.
3. The factory chooses a concrete class with if/else, switch, or a map of creators. A creator is just a small function or object whose job is to build the product.
4. The factory constructs the object and may also inject dependencies, set defaults, or apply caching if that is part of the design.
5. The factory returns the result as an interface or base type, so the caller only sees the contract.
6. The caller uses the object and never needs to know whether it was an EmailNotification, SmsNotification, or something added later.

When and why to use it

• Use it when the code must choose between multiple implementations at runtime.
• Use it when creation rules are messy: parsing config, validating input, picking region-specific providers, or attaching dependencies.
• Use it when you want tests to replace real objects with fake ones through a small creation point.
• Do not use it just because you can. If one class has one obvious constructor and never varies, a plain new is simpler.

Factory vs alternatives

A quick mental model: direct new means the caller knows the recipe, while a factory means the caller only knows the order. The factory may create one object, reuse a cached object, or wire a whole object graph. The pattern does not force new instances every time; it only centralizes the decision.

Performance, complexity, and Java notes

The selection cost is usually tiny. A switch is effectively O(1) for a small number of cases, and a HashMap registry is average O(1) lookup. The real cost is almost always the object construction itself, not the factory call. For most Java services, the difference between direct construction and a factory is measured in microseconds, so choose the pattern for maintainability, not speed. If the factory uses reflection, file I/O, or network calls, the cost can grow quickly and should be justified. There is no special Java version requirement for the pattern; modern Java can make factories cleaner with maps and lambdas, but the basic idea works in every version.

Edge cases and gotchas

• Unknown type: throw a clear exception or return a safe result; do not fail later with a confusing null error.
• Null or blank input: validate early, because factories are often the first boundary where bad input enters.
• Thread safety: if you keep a mutable registry, use safe concurrent structures such as ConcurrentHashMap.
• Overengineering: a factory with one product and no variation is extra noise.
• Testing: if the factory is static and hard-coded everywhere, it can become harder to substitute in tests.

Real-World Story: Imagine an e-commerce checkout service that supports card payments, wallet payments, and bank transfers. At first, the team wrote new calls directly inside several controllers and service classes. That worked until the company added a new payment provider for one region and changed the rules for currency-specific adapters.

The bug appeared because one code path still created the old payment class directly, while another used the new provider. Some users saw orders stuck in payment pending, retries spiked, and support tickets said, “I was charged, but the order never completed.” Logs showed messages like Unknown payment type and No API key configured because construction and validation were scattered across the codebase.

After moving creation into a factory, the team had one place to normalize the provider name, validate config, and choose the right payment implementation. That made rollout safer: adding a new provider became a factory change plus tests, not a hunt through multiple services. This is exactly where factories shine in production: they reduce copy-paste creation logic and prevent inconsistent object setup.

Follow-up & Tricky Questions:

• What is the difference between Factory Pattern and Abstract Factory? A simple factory picks one product from a small set, while an abstract factory creates related families of products. If you need matching objects such as buttons and text boxes for Windows vs Mac, abstract factory is the better fit.
• What is the difference between Factory Pattern and Builder? A factory chooses which object to create, while a builder focuses on how to construct one complex object step by step. Builders are common when an object has many optional fields.
• Can a factory return the same object every time? Yes. A factory may return a new instance, a cached instance, or a singleton if that fits the design. The pattern controls creation logic; it does not force one allocation strategy.
• How do you test code that uses a factory? Prefer depending on an interface or injecting a factory instead of calling static creation everywhere. Then tests can replace the real factory or product with a fake one.
• When would you avoid a factory? If the object is simple, stable, and only has one obvious constructor, a factory adds indirection without much value. In that case, direct construction is often the cleanest choice.
• Is a static method always a Factory Pattern? No. A static method can be a simple factory, but the broader GoF Factory Method pattern is about letting subclasses decide which object to create.
• Does a factory improve performance? Not by itself. Its main value is cleaner design; performance only improves if the factory also avoids repeated setup or enables caching.
• Tricky: Is new bad in Java? No. Direct new is perfectly fine for simple, stable objects. The factory pattern is for when creation logic is likely to change or needs to be centralized.
• Tricky: Should a factory return concrete classes? Usually no. Returning an interface or base type gives the caller flexibility and keeps the factory useful.
• Tricky: Does the pattern guarantee one instance per type? No. That is a caching or singleton decision, not a requirement of the factory pattern itself.

Common Mistakes:

• Mistake: Using a factory for a single class with one constructor. Correction: Use direct construction until there is real variation.
• Mistake: Returning null for unknown input. Correction: Throw a clear exception or handle absence explicitly.
• Mistake: Exposing concrete classes to callers. Correction: Return an interface or base class so the caller stays decoupled.
• Mistake: Mixing business logic into the factory. Correction: Keep the factory focused on creation, selection, and setup.

Memory Hook: You order, the kitchen decides. The caller asks for a product, and the factory quietly chooses how to build it.

Cheat Sheet:

• Factory = centralized object creation.
• Caller depends on interface, not concrete class.
• Great for runtime choice, validation, and cleanup of new calls.
• Simple factory, Factory Method, and Abstract Factory are related but not identical.
• Selection is usually O(1); the real cost is object creation.
• Use it for variation; skip it for trivial stable objects.

Practice Tasks:

• Build a small LoggerFactory that creates console and file loggers.
• Add a new WhatsAppNotification type and update the factory with one change only.
• Replace the switch with a Map<String, Supplier<Notification>> registry and compare the design.