आप किसी domain को अच्छी तरह से डिज़ाइन की गई classes में कैसे मॉडल करते हैं?

Question

Accepted Answer

अच्छी class मॉडलिंग का अर्थ है ऐसी classes जो वास्तविक domain अवधारणाओं से मेल खाती हों, प्रत्येक की **एक स्पष्ट जिम्मेदारी** हो, ईमानदार **is-a/has-a** संबंधों के माध्यम से जुड़ी हों, और सीमाओं पर **abstractions** पर निर्भर हों। कोई सूत्र नहीं है, लेकिन एक दोहराने योग्य प्रक्रिया है। ## एक व्यावहारिक प्रक्रिया ```text 1. Find the NOUNS → candidate classes (Order, Customer, Payment) 2. Find the VERBS → candidate behaviors/methods (place, refund, ship) 3. Assign each behavior to the class that OWNS the data it needs (high cohesion) 4. Choose relationships: IS-A (rare, must pass LSP) vs HAS-A (default) 5. Depend on interfaces at boundaries (DIP); inject volatile dependencies 6. Keep invariants inside the object (encapsulation); prefer immutability for values ``` ## Behavior डेटा का अनुसरण करता है ```java // ❌ logic separated from data (anemic) → low cohesion class Order { List items; } class OrderCalculator { double total(Order o) {...} } // ✅ behavior lives with the data it operates on class Order { private final List items; public Money total() { // owns its own rule return items.stream().map(Item::price).reduce(Money.ZERO, Money::plus); } } ``` ## ऐसी heuristics जो hierarchies को स्वस्थ रखती हैं | Heuristic | Why | |---|---| | Prefer composition; use inheritance only for true is-a | Avoids fragile base class / LSP traps | | Keep hierarchies shallow (2–3 levels) | Deep trees couple everything | | One reason to change per class (SRP) | Localizes change | | Program to interfaces at seams | Testability, swappability | | Make value objects immutable | Eliminates a class of bugs | ## समस्या पहले से *पूरी* दुनिया को मॉडल न करें। concrete classes के साथ छोटे से शुरू करें; abstractions तभी निकालें जब वास्तविक विविधता प्रकट हो (rule of three)। अनुमान-आधारित hierarchies खराब तरीके से पुरानी पड़ती हैं। ## यह क्यों महत्वपूर्ण है एक मॉडल जो domain को प्रतिबिंबित करता है, code को स्वयं-व्याख्यात्मक बनाता है — एक नया engineer `order.refund()` पढ़ता है और व्यवसाय को समझता है, केवल syntax को नहीं। लाभ बढ़ता जाता है: cohesive, ढीले-युग्मित classes परिवर्तन को स्थानीयकृत करती हैं, इसलिए features और bug fixes पूरे system में फैलने के बजाय कुछ ही files को छूते हैं।

Heuristic	Why
Prefer composition; use inheritance only for true is-a	Avoids fragile base class / LSP traps
Keep hierarchies shallow (2–3 levels)	Deep trees couple everything
One reason to change per class (SRP)	Localizes change
Program to interfaces at seams	Testability, swappability
Make value objects immutable	Eliminates a class of bugs