संरचना, आपको कैसे पता चलेगा कि कब रुकना है?

Question

पुरानी लेकिन बुद्धिमान कहानियां "विरासत पर मूल्य संरचना" है। मैं पिछले कुछ परियोजनाओं के लिए अन्य ओओपी और डिजाइन-पैटर्न के साथ इसे लागू करने की कोशिश कर रहा हूं, जिसमें मैंने शामिल किया है।

ज्यादातर मामलों के लिए, यह ठीक काम करता है और दयालु दिखता है सही। लेकिन मैंने देखा है कि कुछ बार, केवल 2 या 3 कक्षाएं होती हैं जो वास्तव में इससे सर्वश्रेष्ठ होती हैं, जबकि अन्य 10+ कक्षाएं अचानक मामूली बदलते विवरणों के साथ सरल प्रतिनिधि बन जाती हैं।

कभी-कभी, मैं असंगत विवरणों के साथ एक अमूर्त वर्ग का उपयोग करके इसे ठीक करने का प्रयास करता हूं जो अलग-अलग लोगों को ठोस कार्यान्वयन के लिए प्रतिनिधि करता है, लेकिन कुछ इसके बारे में पूरी तरह से सही नहीं लगता है।

आप इसका संतुलन कैसे रखते हैं और एक ही समय में पुरानी बुद्धिमानी का पालन करते हैं? क्या मुझसे कुछ गलत हो रही है?

Answer 1

मुझे लगता है कि आपकी समस्या यह हो सकती है कि आप "पुरानी बुद्धिमान कहानियों" का पालन करने की कोशिश कर रहे हैं। आप शायद किसी भी सामान्य दिशानिर्देशों की तुलना में आवेदन की आवश्यकताओं को बेहतर ढंग से जानते हैं।

एक बार जब आप कुछ अनुभव निर्माण अनुप्रयोग एकत्र कर लेते हैं, तो आपको चीजों को कैसे करना है इसके लिए प्राकृतिक अनुभव होना चाहिए। गाइड सिर्फ यही है, गाइड आपको एक अवधारणा को समझने में मदद करने के लिए। वे अपने आप में नियम नहीं हैं।

Answer 2

"विरासत पर मूल्य संरचना" एक पुरानी कहावत है जो आज भी मान्य है। डुप्लिकेट कोड को कम करने के लिए पुन: प्रयोज्य & को बढ़ाने के लिए संरचना और विरासत का मतलब है। विरासत में अन्य लाभ भी हैं।

संरचना का अर्थ है कि यदि आपके पास 2 या अधिक वर्ग पदानुक्रम से संबंधित सामान्य विधि है, तो इसे एक नई कक्षा के रूप में अलग करें और वर्ग पदानुक्रमों को रचना के हिस्से के रूप में इस नई श्रेणी में रहने दें। इसके साथ आप कक्षा पदानुक्रम को अभी तक नहीं छूते हैं, आपको पुन: प्रयोज्य कोड का लाभ मिलता है।

class Aves { ... } 
class Hawk: Aves { ... } 

class Mammal { ... } 
class Bat: Mammal { ... } 

उपरोक्त उदाहरण में, सभी एविस (पक्षी) फ्लाई(), (पेंग्विन या दोदो अभी भी तरह उड़ने में असमर्थ पक्षियों मक्खी() कोई मक्खी के साथ लागू कर सकते हैं)। लेकिन चमगादड़ जो एक स्तनपायी भी उड़ सकता है()

अब आप एक अलग वर्ग और (फ्लाई() एविस के हिस्से के रूप सहित) विरासत से अधिक पक्ष संरचना के रूप में फ्लाई() बाहर खींच सकते हैं

class FlyBehavior 
{ 
public void Fly() { ... } 
} 

उदाहरण के लिए FlyBehavior ShortFlightBehavior और LongFlightBehavior के साथ एक श्रेणी पदानुक्रम हो सकता है।

मुझे आशा है कि मैं तुम्हें आगे भ्रमित नहीं है :)

Answer 3

ऐसा लगता है कि आप एक निरपेक्ष में अनुमानी ज्ञान बदल रहे हैं। यह आपको विरासत का उपयोग करने के लिए "कभी नहीं" नहीं बता रहा है। यदि आप ऐसी परिस्थिति में हैं जहां विरासत या संरचना समान रूप से अच्छी तरह से काम करती है, तो संरचना का उपयोग करें। सरल।

Answer 4

कब रुकना है? संरचना पर ध्यान केंद्रित करना बंद करो। यदि आप अन्य नियमों पर ध्यान केंद्रित करते हैं तो यह स्वाभाविक रूप से आ जाएगा।

इसके बजाय उचित विरासत प्राप्त करने के लिए "is-a" और SRP पर फ़ोकस करें।

कक्षाओं के लिए एसआरपी की जांच करने का सबसे आसान तरीका प्रत्येक विधि नाम को कक्षा के नाम से जोड़ने का प्रयास करना है।

class Vehicle 
{ 
    private void WriteLog(string message) {} 
    public void Start(); 
} 

WriteLog विधि वास्तव में Vehicle के साथ जुड़ा नहीं जा सकता है। इसे तोड़ दें और इसे इसके बजाय निर्माता (संरचना और निर्भरता इंजेक्शन) के माध्यम से ले जाएं।