Factory Method Pattern | Java Backend Developer Master Program

1. Learning Outcomes#

इस chapter को पूरा करने के बाद आप:

समझ पाएँगे कि Factory Method Pattern किस object-creation problem को solve करता है।
पहचान पाएँगे कि direct new usage कब client code को concrete classes से tightly coupled बनाता है।
Product, Concrete Product, Creator, और Concrete Creator की roles समझ पाएँगे।
common Product abstraction के पीछे का कारण समझ पाएँगे।
object creation को Factory Method के through delegate करना सीखेंगे।
inheritance और polymorphism का उपयोग Factory Method implementation में समझ पाएँगे।
direct construction और Factory Method based construction में अंतर समझ पाएँगे।
समझ पाएँगे कि Factory Method extensibility और Open/Closed Principle को कैसे support करता है।
Factory Method, Simple Factory और Abstract Factory के बीच practical difference पहचान पाएँगे।
Java applications में Factory Method के useful use cases और trade-offs समझ पाएँगे।
unnecessary factory layers बनाकर overengineering करने से बच पाएँगे।

2. एक simple problem से शुरुआत करते हैं#

मान लीजिए हम notification भेजने वाला application बना रहे हैं।

शुरुआत में application केवल email भेजता है।

इसलिए code में हम सीधे object बनाते हैं:

JAVA

EmailNotification notification = new EmailNotification();
notification.send("Order confirmed");

अभी यह code बिल्कुल ठीक दिखता है।

लेकिन कुछ समय बाद requirement आती है:

Email notification चाहिए।
SMS notification चाहिए।
Push notification भी चाहिए।

अब client code अलग-अलग concrete classes बनाना शुरू कर सकता है:

JAVA

if (type.equals("email")) {
    EmailNotification notification = new EmailNotification();
} else if (type.equals("sms")) {
    SmsNotification notification = new SmsNotification();
} else if (type.equals("push")) {
    PushNotification notification = new PushNotification();
}

Problem केवल if-else बड़ा होने की नहीं है।

असल problem यह है कि object use करने वाला code object create करने की responsibility भी संभाल रहा है।

यानी client को पता होना चाहिए:

कौन-सी concrete class instantiate करनी है,
constructor कौन-सा है,
नई implementation आने पर कहाँ code बदलना है।

यहीं Factory Method useful होता है।

Key Idea

Factory Method object creation की responsibility को एक अलग overridable method के पीछे रखता है, ताकि बाकी business logic concrete class creation से कम coupled रहे।

3. Direct object creation tight coupling कैसे बनाता है?#

यहाँ new keyword गलत नहीं है।

Java में object बनाने के लिए अंततः कहीं न कहीं constructor call होना ही है।

Problem तब होती है जब application के कई important हिस्से concrete implementation को directly instantiate करने लगते हैं।

उदाहरण:

JAVA

public class NotificationService {

    public void notifyUser(String message) {
        EmailNotification notification = new EmailNotification();
        notification.send(message);
    }
}

NotificationService अब EmailNotification से directly जुड़ा हुआ है।

कल हमें SMS support करना हो तो NotificationService को बदलना पड़ेगा।

इसका मतलब यह class केवल notification भेजने की business responsibility नहीं संभाल रही है। यह यह decision भी ले रही है कि कौन-सा notification object create होगा।

Tight coupling का mental model#

Visual Diagram80%

Rendering diagram…

यह relation हमें बताता है कि high-level workflow concrete implementation की creation detail जानता है।

अगर concrete class बदलती है, तो workflow code पर भी असर पड़ सकता है।

4. Factory Method का मूल intent#

Factory Method का मुख्य intent है:

Object creation के लिए एक method define करना, लेकिन actual concrete object कौन-सा बनेगा यह subclass को decide करने देना।

इसे छोटे steps में समझते हैं।

पहले हमारे पास एक common type होगा:

JAVA

public interface Notification {
    void send(String message);
}

अब अलग implementations इस common abstraction को implement करेंगी:

JAVA

public class EmailNotification implements Notification {

    @Override
    public void send(String message) {
        System.out.println("Email: " + message);
    }
}

JAVA

public class SmsNotification implements Notification {

    @Override
    public void send(String message) {
        System.out.println("SMS: " + message);
    }
}

अब बाकी application केवल Notification abstraction के साथ काम कर सकता है।

लेकिन एक प्रश्न अभी बचा है:

EmailNotification या SmsNotification object बनाएगा कौन?

यहीं Creator आता है।

5. Factory Method की मुख्य roles#

Factory Method structure को समझने के लिए चार roles याद रखें।

Role	Responsibility
Product	common abstraction define करता है
Concrete Product	Product की actual implementation देता है
Creator	Factory Method declare करता है और Product abstraction के साथ काम करता है
Concrete Creator	Factory Method override करके specific Concrete Product create करता है

इन roles को हमारे notification example से map करें:

Factory Method Role	Example
Product	`Notification`
Concrete Product	`EmailNotification`, `SmsNotification`
Creator	`NotificationCreator`
Concrete Creator	`EmailNotificationCreator`, `SmsNotificationCreator`

अब पूरा relation visual रूप में देखें।

Visual Diagram80%

Rendering diagram…

अब प्रत्येक role को धीरे-धीरे समझते हैं।

6. Product abstraction क्यों चाहिए?#

यदि Creator method सीधे EmailNotification return करे, तो Creator फिर उसी concrete implementation से जुड़ जाएगा।

इसलिए हमें एक common abstraction चाहिए।

JAVA

public interface Notification {
    void send(String message);
}

इस interface का मतलब है:

जो भी class Notification है, उसमें send() behavior उपलब्ध होगा।

Creator को यह जानने की आवश्यकता नहीं कि actual object Email है या SMS।

उसे केवल इतना पता है कि उसे Notification मिलेगा और वह उस पर send() call कर सकता है।

यही polymorphism का practical benefit है।

7. Concrete Products#

अब Product abstraction की अलग implementations बनाते हैं।

JAVA

public class EmailNotification implements Notification {

    @Override
    public void send(String message) {
        System.out.println("Email: " + message);
    }
}

JAVA

public class SmsNotification implements Notification {

    @Override
    public void send(String message) {
        System.out.println("SMS: " + message);
    }
}

दोनों classes का behavior अलग है।

लेकिन दोनों का common contract एक है:

JAVA

Notification

इसलिए बाकी design उन्हें common type के through handle कर सकता है।

8. Creator क्या करता है?#

अब एक abstract Creator class बनाते हैं।

JAVA

public abstract class NotificationCreator {

    public abstract Notification createNotification();

    public void notifyUser(String message) {
        Notification notification = createNotification();
        notification.send(message);
    }
}

यहाँ दो methods पर ध्यान दें।

पहला:

JAVA

public abstract Notification createNotification();

यह हमारा Factory Method है।

Creator यह declare करता है कि:

मुझे एक Notification object चाहिए।

लेकिन Creator यह नहीं बताता कि वह EmailNotification होगा या SmsNotification।

दूसरा method है:

JAVA

public void notifyUser(String message)

यह actual workflow है।

इस workflow को concrete class जानने की आवश्यकता नहीं है।

वह केवल:

Factory Method call करता है।
उसे Notification मिलता है।
उस abstraction पर send() call करता है।

यह Factory Method Pattern का बहुत important हिस्सा है।

Factory Method केवल object-returning method नहीं है। Pattern का फायदा तब दिखता है जब common workflow creation को overridable method के पीछे रखता है।

9. Concrete Creator actual object कैसे चुनता है?#

अब Email के लिए Creator subclass बनाएँ:

JAVA

public class EmailNotificationCreator extends NotificationCreator {

    @Override
    public Notification createNotification() {
        return new EmailNotification();
    }
}

SMS के लिए:

JAVA

public class SmsNotificationCreator extends NotificationCreator {

    @Override
    public Notification createNotification() {
        return new SmsNotification();
    }
}

अब concrete object creation सही जगह चली गई है।

EmailNotificationCreator को पता है कि EmailNotification बनाना है।

SmsNotificationCreator को पता है कि SmsNotification बनाना है।

Base Creator का workflow दोनों cases में वही रहता है।

10. पूरा working example#

अब सभी pieces को एक साथ देखते हैं।

JAVA

interface Notification {
    void send(String message);
}

class EmailNotification implements Notification {

    @Override
    public void send(String message) {
        System.out.println("Email: " + message);
    }
}

class SmsNotification implements Notification {

    @Override
    public void send(String message) {
        System.out.println("SMS: " + message);
    }
}

abstract class NotificationCreator {

    public abstract Notification createNotification();

    public void notifyUser(String message) {
        Notification notification = createNotification();
        notification.send(message);
    }
}

class EmailNotificationCreator extends NotificationCreator {

    @Override
    public Notification createNotification() {
        return new EmailNotification();
    }
}

class SmsNotificationCreator extends NotificationCreator {

    @Override
    public Notification createNotification() {
        return new SmsNotification();
    }
}

public class Main {

    public static void main(String[] args) {
        NotificationCreator emailCreator =
                new EmailNotificationCreator();

        emailCreator.notifyUser("Your order is confirmed.");

        NotificationCreator smsCreator =
                new SmsNotificationCreator();

        smsCreator.notifyUser("Your OTP is 4821.");
    }
}

Expected Output#

TEXT

Email: Your order is confirmed.
SMS: Your OTP is 4821.

यहाँ सबसे important observation यह है कि notifyUser() method में कहीं भी यह नहीं लिखा:

JAVA

new EmailNotification()

या:

JAVA

new SmsNotification()

वह केवल Factory Method call करता है:

JAVA

createNotification()

कौन-सा object मिलेगा, यह runtime पर actual Creator subclass पर depend करता है।

11. Inheritance और polymorphism यहाँ कैसे काम कर रहे हैं?#

इस pattern में दो अलग polymorphic relationships हैं।

पहला Product hierarchy में:

JAVA

Notification notification = new EmailNotification();

या:

JAVA

Notification notification = new SmsNotification();

दो अलग concrete objects को common Notification reference handle कर सकता है।

दूसरा Creator hierarchy में:

JAVA

NotificationCreator creator =
        new EmailNotificationCreator();

या:

JAVA

NotificationCreator creator =
        new SmsNotificationCreator();

Base Creator reference अलग Concrete Creator objects को represent कर सकता है।

यानी Factory Method पुराने inheritance और polymorphism concepts का practical design-level application है।

Remember

Factory Method में subclass केवल business behavior बदलने के लिए नहीं, object creation decision बदलने के लिए भी Factory Method override कर सकता है।

12. Runtime flow वास्तव में क्या है?#

मान लीजिए यह code चलता है:

JAVA

NotificationCreator creator =
        new SmsNotificationCreator();

creator.notifyUser("Payment received.");

Flow step by step:

creator reference का type NotificationCreator है।
Actual object SmsNotificationCreator है।
notifyUser() base Creator में defined है।
notifyUser() के अंदर createNotification() call होता है।
Runtime polymorphism के कारण SmsNotificationCreator.createNotification() चलता है।
वह new SmsNotification() return करता है।
Base workflow उस object पर send() call करता है।

इस flow को visual रूप में देखें।

Visual Diagram80%

Rendering diagram…

Conceptually important बात यह है कि creation decision Concrete Creator में है, जबकि सामान्य workflow Creator hierarchy में reuse किया जा सकता है।

13. Direct Construction बनाम Factory Method#

अब दोनों approaches side by side समझते हैं।

Direct construction#

JAVA

public void sendMessage(String message) {
    EmailNotification notification = new EmailNotification();
    notification.send(message);
}

यह code simple है और छोटे fixed requirement के लिए बिल्कुल acceptable हो सकता है।

लेकिन caller concrete class जानता है।

Factory Method based creation#

JAVA

public abstract class NotificationCreator {

    public abstract Notification createNotification();

    public void sendMessage(String message) {
        Notification notification = createNotification();
        notification.send(message);
    }
}

अब common workflow concrete Product को directly instantiate नहीं करता।

Comparison:

Direct Construction	Factory Method
caller concrete class जानता है	common workflow Product abstraction जानता है
creation और usage साथ हो सकते हैं	creation decision अलग method में जाता है
simple cases में कम code	extensible hierarchy में useful
नई implementation पर existing code बदल सकता है	नया Concrete Creator जोड़ना possible होता है
fewer classes	additional Creator classes लग सकती हैं

इसलिए Factory Method हमेशा direct construction से बेहतर नहीं है।

सही design वही है जो actual change requirement को suit करे।

14. Factory Method और Open/Closed Principle#

Open/Closed Principle का basic idea है:

Software entities को extension के लिए open और unnecessary modification के लिए closed रखने की कोशिश करनी चाहिए।

मान लीजिए अब Push notification जोड़ना है।

पहले नया Product बनाएँ:

JAVA

public class PushNotification implements Notification {

    @Override
    public void send(String message) {
        System.out.println("Push: " + message);
    }
}

फिर नया Concrete Creator:

JAVA

public class PushNotificationCreator extends NotificationCreator {

    @Override
    public Notification createNotification() {
        return new PushNotification();
    }
}

हमने existing NotificationCreator.notifyUser() को modify नहीं किया।

हमने existing Email और SMS creators भी नहीं बदले।

हमने design को extend किया।

यही Factory Method का एक बड़ा benefit है।

लेकिन ध्यान रखें: Open/Closed Principle का मतलब कभी भी code modify न करना नहीं है।

मतलब यह है कि frequently changing variation को ऐसा design देना कि हर नई variation पर stable code repeatedly edit न करना पड़े।

15. नया Product जोड़ने पर workflow कैसे unchanged रहता है?#

Visual Diagram80%

Rendering diagram…

ऊपर common workflow वही है।

नई creation variation नीचे add होती है।

यही separation extensibility improve करती है।

16. एक दूसरा practical example: Document export#

मान लीजिए application reports export करता है।

Common Product:

JAVA

interface Document {
    void generate();
}

Concrete Products:

JAVA

class PdfDocument implements Document {

    @Override
    public void generate() {
        System.out.println("Generating PDF document");
    }
}

JAVA

class HtmlDocument implements Document {

    @Override
    public void generate() {
        System.out.println("Generating HTML document");
    }
}

Creator:

JAVA

abstract class DocumentExporter {

    protected abstract Document createDocument();

    public void export() {
        Document document = createDocument();
        document.generate();
    }
}

Concrete Creators:

JAVA

class PdfExporter extends DocumentExporter {

    @Override
    protected Document createDocument() {
        return new PdfDocument();
    }
}

JAVA

class HtmlExporter extends DocumentExporter {

    @Override
    protected Document createDocument() {
        return new HtmlDocument();
    }
}

अब client appropriate Creator choose कर सकता है:

JAVA

public class ExportDemo {

    public static void main(String[] args) {
        DocumentExporter pdfExporter = new PdfExporter();
        pdfExporter.export();

        DocumentExporter htmlExporter = new HtmlExporter();
        htmlExporter.export();
    }
}

Expected Output#

TEXT

Generating PDF document
Generating HTML document

यह example दिखाता है कि Factory Method केवल notifications तक सीमित नहीं है।

जहाँ एक common process है लेकिन उस process को अलग concrete objects चाहिए, वहाँ यह pattern useful हो सकता है।

17. Factory Method कब पहचानना चाहिए?#

कुछ signals हैं जो Factory Method की आवश्यकता indicate कर सकते हैं।

Signal 1: Base workflow को object चाहिए, लेकिन exact class vary करती है#

उदाहरण:

parser create करना,
document create करना,
notification create करना,
transport object create करना,
UI component create करना।

Signal 2: Subclasses को creation customize करनी है#

अगर अलग subclasses को अलग Product instantiate करना है, Factory Method natural fit हो सकता है।

Signal 3: Concrete construction stable workflow को disturb कर रही है#

यदि हर नया Product आने पर common workflow edit करना पड़ रहा है, creation को isolate करना useful हो सकता है।

Signal 4: Caller को concrete implementation से बचाना है#

Caller ideally abstraction पर काम करे और creation detail किसी specialized Creator को सौंपे।

लेकिन केवल इसलिए Factory Method न बनाएँ क्योंकि code में new दिखाई दे रहा है।

18. क्या हर `new` को Factory Method से replace करना चाहिए?#

नहीं।

यह बहुत common overengineering mistake है।

यह code देखें:

JAVA

User user = new User("Amit");

अगर:

केवल एक User implementation है,
construction simple है,
alternate Product families नहीं हैं,
subclass-based creation की आवश्यकता नहीं है,

तो यहाँ Factory Method hierarchy बनाना unnecessary हो सकता है।

ऐसा करना:

JAVA

abstract class UserCreator {
    abstract User createUser();
}

फिर:

JAVA

class DefaultUserCreator extends UserCreator {
    User createUser() {
        return new User("Amit");
    }
}

सिर्फ extra abstraction create करेगा, meaningful flexibility नहीं।

Common Mistake

Design Pattern का उद्देश्य classes की संख्या बढ़ाना नहीं है। Pattern तभी उपयोग करें जब वह वास्तविक design problem solve करे।

19. Factory Method बनाम Simple Factory#

इन दोनों को beginners अक्सर confuse करते हैं।

Simple Factory सामान्यतः एक method या class में condition के आधार पर object create करती है।

उदाहरण:

JAVA

class NotificationFactory {

    public static Notification create(String type) {
        if ("email".equalsIgnoreCase(type)) {
            return new EmailNotification();
        }

        if ("sms".equalsIgnoreCase(type)) {
            return new SmsNotification();
        }

        throw new IllegalArgumentException(
                "Unsupported notification type: " + type
        );
    }
}

Client:

JAVA

Notification notification =
        NotificationFactory.create("email");

यह useful हो सकता है।

लेकिन यहाँ object choice एक central factory method के अंदर conditional logic से हो रही है।

Factory Method Pattern में creation सामान्यतः inheritance और method overriding के through specialize होती है।

उदाहरण:

JAVA

class EmailNotificationCreator extends NotificationCreator {

    @Override
    public Notification createNotification() {
        return new EmailNotification();
    }
}

मुख्य अंतर:

Simple Factory	Factory Method
अक्सर एक central factory class/method	Creator hierarchy
condition से Product select हो सकता है	subclass override से Product select होता है
inheritance जरूरी नहीं	inheritance/polymorphism central mechanism है
practical idiom है	classic GoF creational pattern है

Interview Point

Simple Factory useful object-creation technique है, लेकिन Gang of Four की original design-pattern list में अलग GoF pattern के रूप में defined नहीं है।

20. Factory Method बनाम Abstract Factory#

नाम similar होने के कारण यह दूसरा common confusion है।

Factory Method सामान्यतः एक Product creation method को subclass के through override करने पर focus करता है।

Abstract Factory सामान्यतः related Products की family create करने के लिए multiple creation operations provide करता है।

Simple mental model:

Factory Method → “इस Product का concrete type कौन-सा बने?”
Abstract Factory → “इस पूरी related Product family के compatible objects कौन बनाए?”

उदाहरण के लिए UI theme को सोचें।

एक Light theme family में हो सकते हैं:

Light Button
Light Checkbox

Dark theme family में:

Dark Button
Dark Checkbox

पूरी compatible family create करनी हो तो Abstract Factory अधिक natural हो सकता है।

लेकिन एक Creator hierarchy में सिर्फ document या notification का concrete object choose करना हो, Factory Method fit हो सकता है।

Factory Method	Abstract Factory
inheritance-based creation customization	object composition के through factory object commonly use होता है
अक्सर one creation method focus	related products के multiple creation methods हो सकते हैं
subclass decides concrete Product	concrete factory decides product family
Creator hierarchy important	Factory interface + Concrete Factories important

यह distinction interview में केवल definition के रूप में याद न करें।

पहले यह देखें कि variation single Product creation की है या related Product family की।

21. Java applications में practical use cases#

Factory Method useful हो सकता है जहाँ framework या base class common lifecycle define करती है लेकिन subclasses specific object creation customize करती हैं।

Typical examples:

notification channels,
document exporters,
parsers,
serializers,
report generators,
payment handlers,
connection-related components,
platform-specific components,
framework extension points।

Real libraries में implementation हमेशा textbook diagram जैसी नहीं दिखेगी।

Pattern का intent पहचानना अधिक important है:

Stable workflow concrete object creation को overridable creation point के पीछे रखता है।

22. Constructor और Factory Method में अंतर#

Constructor object initialize करता है।

Factory Method एक normal method है जो object creation decision को encapsulate कर सकता है।

उदाहरण:

JAVA

public Notification createNotification() {
    return new EmailNotification();
}

यह method internally constructor call कर रहा है।

Factory Method constructor का replacement नहीं है।

वह constructor invocation को सही abstraction point पर रखता है।

23. Java static factory method और Factory Method Pattern एक ही चीज हैं?#

जरूरी नहीं।

Java में ऐसा method:

JAVA

public static User createGuest() {
    return new User("Guest");
}

अक्सर static factory method कहा जाता है।

लेकिन classic GoF Factory Method Pattern का central mechanism subclass overriding होता है।

इसलिए हर method जो object return करे, automatically Factory Method design pattern नहीं बन जाता।

Remember

Method का नाम create(), of(), getInstance() या newInstance() होना Factory Method Pattern prove नहीं करता। Design intent और polymorphic creation structure देखें।

24. Factory Method के फायदे#

1. Concrete creation अलग होती है#

Common workflow को exact Product class जानने की आवश्यकता कम होती है।

2. Extensibility improve हो सकती है#

नई Product variation के लिए नया Concrete Creator add किया जा सकता है।

3. Open/Closed design support करता है#

Stable Creator workflow को हर नई Product type पर modify करने की आवश्यकता कम हो सकती है।

4. Inheritance-based customization point मिलता है#

Framework या base class एक creation hook expose कर सकती है।

5. Product abstraction के साथ programming encourage होती है#

Business logic concrete classes के बजाय common interfaces पर operate कर सकता है।

25. Factory Method के trade-offs#

Pattern benefits देता है, लेकिन free नहीं आता।

अधिक classes#

एक Product के साथ अलग Creator subclass भी बन सकता है।

इससे class count बढ़ती है।

Inheritance dependency#

Factory Method subclass-based customization use करता है।

हर situation में inheritance best choice नहीं होती।

Simple requirement complex बन सकती है#

अगर केवल एक concrete Product है और variation की संभावना भी नहीं है, pattern unnecessary ceremony बन सकता है।

Creator hierarchy समझनी पड़ती है#

Beginner developer के लिए direct construction की तुलना में flow initially अधिक indirect लग सकता है।

इसलिए हमेशा trade-off देखें।

26. कब Factory Method avoid करना चाहिए?#

Factory Method avoid करने पर विचार करें जब:

object creation बहुत simple और fixed है,
केवल एक implementation है,
subclass customization की आवश्यकता नहीं है,
future variation का कोई realistic reason नहीं है,
factory hierarchy business code से अधिक complex हो जाएगी।

Pattern का उपयोग “future में कभी कुछ बदल सकता है” जैसी vague possibility के कारण न करें।

Actual design pressure होना चाहिए।

27. एक छोटा decision guide#

Visual Diagram80%

Rendering diagram…

यह decision chart कोई absolute rule नहीं है।

यह केवल thinking guide है।

Design Pattern selection हमेशा context पर depend करता है।

28. Complete mental model#

Factory Method को एक sentence में समझें:

Common workflow कहता है “मुझे Product दो”; Concrete Creator decide करता है “मैं कौन-सा Product बनाऊँगा।”

उदाहरण:

JAVA

public abstract Notification createNotification();

Base Creator कहता है:

मुझे Notification चाहिए।

Email Creator कहता है:

JAVA

return new EmailNotification();

SMS Creator कहता है:

JAVA

return new SmsNotification();

बाकी workflow Product abstraction के साथ चलता रहता है।

यही pattern का core है।

29. Common Mistakes#

हर object creation को factory बनाना#

यह unnecessary abstraction create कर सकता है।

Product abstraction न बनाना#

अगर Creator concrete type पर ही depend करे, तो polymorphic benefit कम हो सकता है।

Factory Method और Simple Factory को same समझना#

दोनों object creation hide कर सकते हैं, लेकिन mechanism अलग है।

केवल `createX()` method देखकर pattern declare करना#

Method name से नहीं, structure और intent से pattern identify करें।

Base Creator में concrete Products की बड़ी conditional chain रखना#

अगर subclass-based Factory Method design चाहिए, तो हर Product selection को base Creator के if-else में डालना pattern का purpose कमजोर कर सकता है।

Factory Method को Abstract Factory समझना#

Factory Method single polymorphic creation point पर focus करता है; Abstract Factory related Product families पर focus कर सकता है।

30. Interview Preparation#

Interview Question 1Show Answer

Q: What is the Factory Method Pattern?

Answer: Factory Method is a creational design pattern that defines an interface or method for creating a product while allowing subclasses to decide which concrete product is instantiated. It separates reusable workflow logic from concrete object-creation decisions.

सरल शब्दों में, base Creator कहता है कि Product चाहिए, जबकि subclass तय करता है कि exact Product कौन-सा बनेगा।

Interview Question 2Show Answer

Q: How does Factory Method reduce coupling?

Answer: It allows common workflow code to depend on a Product abstraction rather than directly constructing concrete Product classes. Concrete creation is delegated to specialized Creator subclasses.

इससे common logic को हर Product implementation की constructor detail जानने की आवश्यकता कम होती है।

Interview Question 3Show Answer

Q: What is the difference between Factory Method and Simple Factory?

Answer: A Simple Factory commonly uses a centralized method, often with conditional logic, to select and create a Product. Factory Method uses inheritance and method overriding so subclasses determine the concrete Product.

Interview Question 4Show Answer

Q: What is the difference between Factory Method and Abstract Factory?

Answer: Factory Method typically customizes creation of a Product through subclass overriding. Abstract Factory provides an interface for creating families of related or compatible Products.

Interview Question 5Show Answer

Q: What is a disadvantage of Factory Method?

Answer: Factory Method can increase the number of classes because new Product variations may require corresponding Creator subclasses. For simple and stable object creation, this additional abstraction may be unnecessary.

31. Chapter Recap#

इस chapter से सबसे important बातें:

Factory Method object creation को polymorphic creation point के पीछे रखता है।
Product abstraction common behavior define करती है।
Concrete Products actual implementations होती हैं।
Creator Factory Method declare करता है और common workflow रख सकता है।
Concrete Creator Factory Method override करके specific Product बनाता है।
Pattern inheritance और runtime polymorphism का उपयोग करता है।
Direct construction simple cases में सही हो सकती है।
Factory Method useful है जब concrete Product creation vary करती है और common workflow stable रखना है।
यह Open/Closed design support कर सकता है।
Simple Factory और Factory Method का creation mechanism अलग है।
Abstract Factory related Product families create करने की problem solve करता है।
Extra Creator classes complexity बढ़ा सकती हैं।
Pattern तभी use करें जब वह real variation और coupling problem solve करे।

Summary

Factory Method का उद्देश्य new keyword को हटाना नहीं है। इसका उद्देश्य concrete object creation को ऐसे extension point पर रखना है जहाँ creation बदल सके, जबकि common workflow unnecessary changes से बचा रहे।

Role	Responsibility
Product	Declares the common abstraction used by the workflow
Concrete Product	Implements the Product abstraction
Creator	Declares the Factory Method and may contain reusable workflow logic
Concrete Creator	Overrides the Factory Method and creates a specific Concrete Product

Printing is unavailable

1. Learning Outcomes#

2. एक simple problem से शुरुआत करते हैं#

3. Direct object creation tight coupling कैसे बनाता है?#

Tight coupling का mental model#

4. Factory Method का मूल intent#

5. Factory Method की मुख्य roles#

6. Product abstraction क्यों चाहिए?#

7. Concrete Products#

8. Creator क्या करता है?#

9. Concrete Creator actual object कैसे चुनता है?#

10. पूरा working example#

Expected Output#

11. Inheritance और polymorphism यहाँ कैसे काम कर रहे हैं?#

12. Runtime flow वास्तव में क्या है?#

13. Direct Construction बनाम Factory Method#

Direct construction#

Factory Method based creation#

14. Factory Method और Open/Closed Principle#

15. नया Product जोड़ने पर workflow कैसे unchanged रहता है?#

16. एक दूसरा practical example: Document export#

Expected Output#

17. Factory Method कब पहचानना चाहिए?#

Signal 1: Base workflow को object चाहिए, लेकिन exact class vary करती है#

Signal 2: Subclasses को creation customize करनी है#

Signal 3: Concrete construction stable workflow को disturb कर रही है#

Signal 4: Caller को concrete implementation से बचाना है#

18. क्या हर new को Factory Method से replace करना चाहिए?#

19. Factory Method बनाम Simple Factory#

20. Factory Method बनाम Abstract Factory#

21. Java applications में practical use cases#

22. Constructor और Factory Method में अंतर#

23. Java static factory method और Factory Method Pattern एक ही चीज हैं?#

24. Factory Method के फायदे#

1. Concrete creation अलग होती है#

2. Extensibility improve हो सकती है#

3. Open/Closed design support करता है#

4. Inheritance-based customization point मिलता है#

5. Product abstraction के साथ programming encourage होती है#

25. Factory Method के trade-offs#

अधिक classes#

Inheritance dependency#

Simple requirement complex बन सकती है#

Creator hierarchy समझनी पड़ती है#

26. कब Factory Method avoid करना चाहिए?#

27. एक छोटा decision guide#

28. Complete mental model#

29. Common Mistakes#

हर object creation को factory बनाना#

Product abstraction न बनाना#

Factory Method और Simple Factory को same समझना#

केवल createX() method देखकर pattern declare करना#

Base Creator में concrete Products की बड़ी conditional chain रखना#

Factory Method को Abstract Factory समझना#

30. Interview Preparation#

31. Chapter Recap#

18. क्या हर `new` को Factory Method से replace करना चाहिए?#

केवल `createX()` method देखकर pattern declare करना#