1. Learning Outcomes#

2. Design Pattern की जरूरत कहाँ से आती है?#

मान लीजिए आप Java application बना रहे हैं।

शुरुआत में application छोटा है। कुछ classes हैं, थोड़े objects हैं और requirements भी simple हैं।

लेकिन project बढ़ने लगता है।

नई requirements आती हैं।

कुछ classes बार-बार बदलती हैं। एक change करने पर कई दूसरी classes भी modify करनी पड़ती हैं। Testing मुश्किल होने लगती है। Objects के बीच dependencies बढ़ जाती हैं।

अब समस्या Java syntax की नहीं है।

आपको class, interface, inheritance और polymorphism आते हैं।

असल सवाल है:

इन OOP building blocks को किस तरह organize किया जाए ताकि design flexible और maintainable रहे?

यहीं से Design Patterns की जरूरत समझ में आती है।

3. Software Design Pattern क्या है?#

Software development में कुछ design problems अलग-अलग projects में बार-बार दिखाई देती हैं।

उदाहरण के लिए:

• object creation बहुत tightly coupled हो जाना
• existing class को बदले बिना किसी दूसरे component के साथ जोड़ने की जरूरत
• कई objects के बीच communication और responsibilities को manage करना
• बदलते behavior को stable code से अलग रखना

हर project का code अलग हो सकता है, लेकिन underlying design problem समान हो सकती है।

Experienced developers ने ऐसे recurring problems के अच्छे solutions को identify किया, describe किया और नाम दिया।

इसी reusable design knowledge को हम Design Pattern कहते हैं।

एक simple professional definition:

लेकिन यहाँ सबसे महत्वपूर्ण शब्द है approach।

Pattern finished Java code नहीं है।

यह एक design idea है जिसे अपने project की situation के अनुसार implement करना पड़ता है।

एक आसान mental model#

घर बनाते समय architect के पास किसी common problem के लिए proven architectural idea हो सकता है।

उदाहरण के लिए ventilation, room arrangement या entrance flow के लिए कोई established approach।

लेकिन हर घर में वही exact bricks, measurements और rooms copy नहीं किए जाते।

Location, budget और requirement के अनुसार design adapt किया जाता है।

Software Design Pattern के साथ भी यही होता है।

Pattern reusable idea देता है। Final implementation project-specific होती है।

4. Recurring Design Problem को समझना#

Pattern का उपयोग तभी meaningful होता है जब हमें problem सही तरह समझ में आए।

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

आज केवल PDF format है।

कुछ समय बाद Excel format आता है।

फिर CSV format आता है।

यदि हर नया format जोड़ने पर कई unrelated classes modify करनी पड़ें, तो recurring design problem दिखाई दे रही है।

सिर्फ यह कहना पर्याप्त नहीं है:

"हमें code flexible बनाना है।"

हमें situation को थोड़ा structured तरीके से देखना चाहिए।

Context#

Context वह environment या situation है जिसमें problem दिखाई देती है।

हमारे example में:

एक application अलग-अलग formats में reports export करती है।

Problem#

Problem वह recurring design difficulty है जिसे solve करना है।

उदाहरण:

नई report format जोड़ने पर existing code के कई हिस्से बदल रहे हैं।

Forces#

Forces वे competing requirements, constraints या pressures हैं जो design decision को प्रभावित करते हैं।

उदाहरण:

• नई formats आसानी से add होनी चाहिए।
• existing working code कम से कम modify होना चाहिए।
• testing आसान होनी चाहिए।
• design जरूरत से ज्यादा complicated नहीं होना चाहिए।
• development time भी reasonable रहना चाहिए।

यानी एक अच्छा design सिर्फ "flexible" होना पर्याप्त नहीं है।

उसे simplicity, maintainability, testability और project constraints के बीच balance बनाना होता है।

यह relationship visually देखें:

Flow Context से शुरू होता है।

उस context में कोई recurring problem दिखाई देती है।

फिर हम forces समझते हैं।

उसके बाद suitable pattern knowledge useful हो सकती है।

लेकिन pattern directly final code नहीं बनाता। उसे current project के अनुसार adapt करके context-specific design बनाया जाता है।

और हर design के कुछ consequences होते हैं — कुछ benefits और कुछ costs।

5. Design Pattern reusable code क्यों नहीं है?#

यह शुरुआती learners की बहुत common confusion है।

मान लीजिए आपने किसी website से किसी pattern की Java implementation copy की।

उस example में classes हैं:

Client, Service, ConcreteService, Handler

लेकिन आपके project में domain अलग है।

आपके पास शायद:

OrderService, PaymentProvider, NotificationChannel या किसी और प्रकार की classes होंगी।

Pattern का reusable हिस्सा class names नहीं हैं।

Reusable हिस्सा यह knowledge है:

• कौन-सी responsibility अलग करनी चाहिए
• कौन-सा component किस abstraction पर depend करे
• objects आपस में कैसे collaborate करें
• कौन-सी चीज stable रहे
• कौन-सी चीज आसानी से बदल सके
• इस arrangement के बदले हमें कौन-से trade-offs मिलेंगे

इसलिए:

Design Pattern = reusable design knowledge

यह नहीं:

Design Pattern = reusable copy-paste code

6. Pattern को समझने के Core Elements#

किसी Design Pattern को सिर्फ उसका नाम याद करके नहीं समझना चाहिए।

कम से कम पाँच important elements समझने चाहिए:

अब इन्हें एक-एक करके समझते हैं।

Intent#

Intent pattern का उद्देश्य बताता है।

यह मूल सवाल का answer देता है:

"यह pattern किस problem के लिए है?"

अगर intent आपके actual problem से match ही नहीं करता, तो केवल pattern का नाम popular होने के कारण उसे use नहीं करना चाहिए।

Structure#

Structure बताती है कि important participants आपस में किस तरह arranged या connected हैं।

Structure में:

• interface
• abstract class
• concrete class
• composition
• association
• delegation

जैसी OOP relationships दिखाई दे सकती हैं।

Structure को exact code समझने की जरूरत नहीं है।

पहले high-level relationship समझना जरूरी है।

Participants#

Participants pattern में involved roles होते हैं।

ध्यान दें: role और concrete class name एक ही चीज नहीं हैं।

किसी pattern का एक participant "creator", "client", "handler" या "component" जैसी responsibility represent कर सकता है।

आपके actual application में उसी role का नाम domain के अनुसार कुछ और हो सकता है।

Collaborations#

सिर्फ participants जानना पर्याप्त नहीं है।

हमें यह भी समझना होता है कि वे आपस में कैसे काम करते हैं।

यही Collaborations हैं।

उदाहरण के लिए:

• कौन किसे request भेजता है?
• कौन किस abstraction पर depend करता है?
• कौन implementation select करता है?
• responsibility किस object के पास रहती है?

Consequences#

हर pattern के फायदे होते हैं।

लेकिन लगभग हर useful abstraction की कोई cost भी होती है।

Consequences हमें दोनों sides बताते हैं।

उदाहरण:

Benefit:

• code अधिक extensible हो सकता है।

Possible cost:

• extra interfaces या classes बढ़ सकती हैं।

Benefit:

• coupling कम हो सकती है।

Possible cost:

• execution flow beginner के लिए तुरंत समझना कठिन हो सकता है।

इसलिए consequence समझना pattern selection का जरूरी हिस्सा है।

7. एक Pattern को केवल Structure से पहचानना सही क्यों नहीं है?#

दो designs visually similar दिख सकते हैं।

लेकिन उनका Intent अलग हो सकता है।

इसलिए केवल class diagram देखकर pattern identify करना कई बार गलत हो सकता है।

Pattern समझते समय priority रखें:

Problem → Intent → Context → Collaboration → Structure → Consequences

Structure important है, लेकिन structure pattern का पूरा meaning नहीं है।

8. OOP Concepts Design Patterns की Foundation कैसे बनते हैं?#

Design Patterns कोई अलग programming language feature नहीं हैं।

Java में ऐसा कोई keyword नहीं है:

pattern

Patterns सामान्य OOP concepts को thoughtful तरीके से combine करते हैं।

आप पहले OOP में जिन concepts को सीख चुके हैं, वे यहाँ building blocks बनते हैं।

इन concepts को यहाँ दोबारा detail में नहीं सीख रहे हैं।

मुख्य बात यह समझनी है:

Design Patterns OOP features की list नहीं हैं। वे OOP building blocks को recurring design problems solve करने के लिए arrange करने के proven ways हैं।

छोटा Java-oriented example#

मान लीजिए हमारे पास यह abstraction है:

interface NotificationSender {
    void send(String message);
}

और application का कोई service सीधे specific implementation पर depend करने के बजाय NotificationSender contract पर depend करता है।

यहाँ महत्वपूर्ण बात syntax नहीं है।

महत्वपूर्ण बात यह है कि हमने:

• responsibility अलग की
• abstraction बनाई
• implementation detail को client से अलग किया

यही प्रकार की design thinking आगे patterns समझने में काम आती है।

इस छोटे example को किसी specific GoF pattern का complete implementation समझने की जरूरत नहीं है। यहाँ केवल OOP foundation और design thinking समझना महत्वपूर्ण है।

9. GoF का मतलब क्या है?#

Design Patterns की चर्चा में आप अक्सर GoF शब्द सुनेंगे।

GoF का मतलब है Gang of Four।

यह नाम उन चार authors के लिए use किया जाता है जिन्होंने classic book Design Patterns: Elements of Reusable Object-Oriented Software लिखी:

• Erich Gamma
• Richard Helm
• Ralph Johnson
• John Vlissides

इस work ने 23 classic object-oriented design patterns को popular classification में organize किया।

इन patterns को तीन major categories में रखा जाता है:

1. Creational
2. Structural
3. Behavioral

इन categories का purpose pattern names याद करवाना नहीं है।

इनका purpose यह समझने में मदद करना है कि design problem मुख्य रूप से creation, structure, या behavior/collaboration से related है।

10. GoF की तीन Categories#

पहले पूरे mental model को visually देखें:

इस diagram में तीन branches हैं।

Creational branch creation-related decisions पर focus करती है।

Structural branch classes और objects को larger structure में जोड़ने पर focus करती है।

Behavioral branch objects के behavior, responsibilities और communication पर focus करती है।

अब इन्हें detail में समझते हैं।

Creational Patterns#

Creational patterns का मुख्य concern है:

Objects कैसे create किए जाएँ?

Simple application में हम अक्सर सीधे object बनाते हैं।

लेकिन larger systems में creation decision complicated हो सकती है।

उदाहरण:

• exact class runtime situation पर depend करती है
• object creation expensive है
• caller को concrete implementation नहीं जाननी चाहिए
• कई related objects consistent तरीके से create करने हैं

ऐसी situations में creation logic को better organize करने की जरूरत हो सकती है।

Creational patterns इसी प्रकार की design problems को address करते हैं।

Structural Patterns#

Structural patterns का मुख्य concern है:

Classes और objects को किस तरह connect या compose किया जाए?

कई बार existing components individually ठीक होते हैं।

Problem तब आती है जब:

• दो incompatible components को साथ काम कराना हो
• complex subsystem को simple interface देना हो
• object hierarchy को flexible structure में organize करना हो
• additional responsibility जोड़नी हो

Structural patterns इस बात पर focus करते हैं कि pieces को किस तरह arrange किया जाए ताकि overall design manageable रहे।

यह building blocks को intelligently जोड़ने के बारे में है।

Behavioral Patterns#

Behavioral patterns का मुख्य concern है:

Objects आपस में communicate कैसे करें और responsibilities कैसे बाँटें?

Application में कई objects होते हैं।

अगर हर object हर दूसरे object की internal detail जानने लगे, तो coupling बढ़ सकती है।

Behavioral design problems में अक्सर सवाल होते हैं:

• कौन request handle करेगा?
• किस object के पास कौन-सी responsibility होनी चाहिए?
• बदलते behavior को कैसे organize करें?
• objects के बीच communication कैसे control करें?
• workflow या interaction को कैसे flexible रखें?

Behavioral patterns इस तरह की collaboration-related problems को organize करते हैं।

11. तीन Categories को एक साथ Compare करें#

एक useful memory shortcut:

Create → Connect → Collaborate

Creational → Create

Structural → Connect

Behavioral → Collaborate

यह सिर्फ याद रखने का तरीका है। Actual pattern choose करते समय context और intent समझना जरूरी है।

12. Design Pattern और Algorithm में अंतर#

Design Pattern और Algorithm दोनों reusable knowledge हैं, लेकिन दोनों का purpose अलग है।

Algorithm#

Algorithm किसी computational problem को solve करने के लिए step-by-step procedure देता है।

उदाहरण:

sorting के लिए कोई algorithm यह define कर सकता है कि elements किस sequence में compare और rearrange होंगे।

Design Pattern#

Design Pattern application के design में responsibilities, relationships और collaboration organize करने का approach देता है।

इसलिए:

Algorithm पूछता है:
"Problem solve करने के steps क्या हैं?"

Design Pattern पूछता है:
"Software components को किस तरह organize करें?"

एक ही Design Pattern की implementation अलग-अलग projects में काफी अलग दिखाई दे सकती है।

Algorithm के steps comparatively अधिक precise होते हैं।

13. Design Pattern और Library में अंतर#

Library reusable code देती है।

उदाहरण:

JSON processing library आपको ready-made classes और methods देती है।

आप उस API को call कर सकते हैं।

Design Pattern ready-made executable library नहीं देता।

वह reusable design idea देता है।

एक library internally कई design patterns use कर सकती है।

लेकिन केवल इसलिए library को design pattern नहीं कहा जाता।

14. Design Pattern और Framework में अंतर#

Framework application के लिए एक बड़ा reusable infrastructure या architectural skeleton दे सकता है।

Framework में:

• lifecycle
• APIs
• conventions
• extension points
• reusable implementation

हो सकते हैं।

Design Pattern framework से छोटा conceptual design solution होता है।

Framework अपने internal architecture में कई patterns use कर सकता है।

उदाहरण के लिए कोई framework object creation, event handling या extension mechanism के लिए अलग-अलग patterns employ कर सकता है।

लेकिन:

Framework = reusable software infrastructure

Pattern = reusable design knowledge

15. Design Pattern और Design Principle में अंतर#

Design Principle broad guidance देता है।

उदाहरण के लिए principle कह सकता है:

high-level code को unnecessary concrete details से tightly coupled नहीं होना चाहिए।

यह direction देता है।

लेकिन exact structure नहीं बताता।

Design Pattern किसी recurring problem के लिए roles, relationships और collaboration का अधिक concrete design approach देता है।

इसलिए:

Principle बताता है कि good design किस दिशा में जाना चाहिए।

Pattern दिखाता है कि कुछ recurring situations में उस दिशा को structure में कैसे express किया जा सकता है।

Principles और patterns competitors नहीं हैं।

वे अक्सर एक-दूसरे को support करते हैं।

16. Quick Comparison#

17. Pattern-Based Design के Benefits#

सही situation में pattern useful हो सकता है।

Shared Vocabulary#

अगर experienced developers कहते हैं:

"यहाँ creation responsibility अलग करनी चाहिए।"

तो पूरी explanation लंबी हो सकती है।

एक established pattern name team को shared vocabulary दे सकता है।

लेकिन vocabulary तभी useful है जब team pattern का intent समझती हो।

Proven Design Knowledge#

Patterns common problems पर accumulated experience represent करते हैं।

Developer को हर recurring design problem zero से invent नहीं करनी पड़ती।

Better Separation of Responsibilities#

कई patterns responsibilities को clearer roles में divide करने में मदद करते हैं।

इससे code reasoning और testing improve हो सकती है।

Extensibility#

सही context में pattern future variations add करना आसान बना सकता है।

Maintainability#

Responsibilities और dependencies clearer होने पर maintenance आसान हो सकती है।

लेकिन यहाँ एक महत्वपूर्ण शब्द है:

सही context में।

Pattern अपने आप maintainability guarantee नहीं करता।

18. Pattern के Trade-Offs#

Patterns के benefits देखकर ऐसा लग सकता है कि ज्यादा patterns का मतलब ज्यादा अच्छा architecture।

यह गलत conclusion है।

More Classes and Interfaces#

Pattern apply करने से extra abstractions आ सकती हैं।

छोटे problem में यह unnecessary हो सकता है।

More Indirection#

Direct call समझना आसान होता है।

जब बीच में interfaces, collaborators और delegation layers बढ़ती हैं, execution flow trace करना कठिन हो सकता है।

Learning Cost#

Team को pattern का intent और implementation दोनों समझना पड़ता है।

Wrong Abstraction Cost#

अगर आपने गलत pattern choose किया, तो design simple होने के बजाय अधिक rigid या confusing हो सकता है।

Premature Flexibility#

कभी-कभी developer ऐसी future requirement के लिए abstraction बनाता है जिसका आना निश्चित ही नहीं है।

ऐसी speculative flexibility codebase को unnecessarily complicated कर सकती है।

19. Pattern कैसे Choose करें?#

Pattern selection की शुरुआत pattern catalog से नहीं करनी चाहिए।

पहले problem समझनी चाहिए।

एक practical thinking flow यह है:

इस flow में सबसे पहले Design Problem आता है।

फिर context और forces समझे जाते हैं।

उसके बाद एक बहुत important सवाल है:

क्या simple design ही पर्याप्त है?

अगर answer Yes है, तो pattern लगाने की कोई मजबूरी नहीं है।

अगर simple design problem solve नहीं कर रही, तब candidate pattern का Intent compare किया जाता है।

फिर उसके consequences और trade-offs evaluate किए जाते हैं।

अगर trade-offs acceptable हैं, तभी pattern को project context के अनुसार adapt करना चाहिए।

20. Pattern Popularity के आधार पर Choose क्यों नहीं करना चाहिए?#

कुछ pattern names industry में बहुत popular होते हैं।

इससे beginner को लग सकता है:

"यह famous pattern है, इसलिए इसे मेरे project में भी use करना चाहिए।"

लेकिन pattern कोई badge नहीं है।

Pattern का value उसके fit में है।

एक pattern तभी useful है जब:

• problem उसके intent से match करता हो
• context suitable हो
• forces उस structure को justify करती हों
• consequences acceptable हों

अगर ये conditions नहीं हैं, तो popular pattern भी wrong design choice हो सकता है।

21. Pattern Overuse क्या है?#

Pattern overuse का मतलब है वहाँ भी pattern लगा देना जहाँ simpler solution पर्याप्त था।

उदाहरण के लिए:

एक application में केवल एक simple stable behavior है।

Variation का कोई realistic requirement नहीं है।

फिर भी developer:

• interface बनाता है
• abstract class बनाता है
• multiple implementation layers बनाता है
• factory-like creation layer बनाता है

सिर्फ इसलिए क्योंकि architecture "advanced" दिखना चाहिए।

ऐसा design technical रूप से valid हो सकता है।

लेकिन maintainability खराब कर सकता है।

इसे अक्सर overengineering कहा जाता है।

22. Forced Pattern Application#

Forced pattern application में developer पहले pattern choose करता है और फिर problem को उस pattern में fit करने की कोशिश करता है।

सोच कुछ ऐसी होती है:

"मैंने नया pattern सीखा है। अब इसे project में कहाँ लगा सकता हूँ?"

Better सोच है:

"मेरे design में actual recurring problem क्या है? क्या किसी known pattern का intent इससे naturally match करता है?"

इस difference को हमेशा याद रखें।

23. Common Beginner Mistakes#

Pattern को Code Template समझना#

Pattern का example implementation learning के लिए होता है।

उसे production code में blindly copy नहीं करना चाहिए।

Pattern Name पहले Choose करना#

पहले problem और context समझें।

Pattern बाद में choose करें।

Intent Ignore करना#

Class diagram याद करके pattern use करना dangerous है।

Intent pattern का central meaning है।

Consequences Ignore करना#

Pattern के फायदे के साथ उसकी complexity भी evaluate करें।

हर Abstraction को Pattern समझना#

हर interface, inheritance hierarchy या composition Design Pattern नहीं होती।

Patterns specific recurring design intent represent करते हैं।

ज्यादा Patterns को Better Design समझना#

Good architecture pattern count से measure नहीं होती।

Simplicity भी एक important design quality है।

24. Interview Preparation#

25. इस Chapter से क्या याद रखना है?#

• Design Pattern recurring design problem के लिए reusable design knowledge है।
• Pattern finished Java code नहीं है।
• Pattern समझने से पहले context, problem और forces समझना जरूरी है।
• Pattern के important elements हैं: Intent, Structure, Participants, Collaborations और Consequences।
• Design Patterns OOP concepts जैसे abstraction, polymorphism, composition और delegation का thoughtful use करते हैं।
• GoF patterns की तीन categories हैं:
  • Creational — creation
  • Structural — composition
  • Behavioral — collaboration
• Algorithm procedure देता है; pattern design organization देता है।
• Library reusable code देती है; pattern reusable design idea देता है।
• Framework reusable infrastructure देता है; pattern smaller design knowledge देता है।
• Design Principle guidance देता है; pattern recurring situation के लिए more concrete design approach देता है।
• Pattern के benefits के साथ complexity और trade-offs भी आते हैं।
• Pattern का चुनाव popularity से नहीं, problem + context + forces + consequences देखकर करें।
• जहाँ simple design पर्याप्त है, वहाँ unnecessary pattern लगाना overengineering बन सकता है।