कोड पूर्ण 2, रचना और प्रतिनिधिमंडल

Question

इस मंच पर पढ़ने के कुछ हफ्तों बाद मैंने सोचा कि यह मेरे लिए पहली पोस्ट करने का समय था।

मैं वर्तमान में कोड पूर्ण को फिर से पढ़ रहा हूं। मुझे लगता है कि यह आखिरी बार 15 साल है, और मुझे लगता है कि मैं अभी भी कोड नहीं लिख सकता ;-)

वैसे भी कोड 138 पर कोड पूर्ण होने पर आपको यह कोडिंग डरावनी उदाहरण मिल जाता है। (मैंने कुछ कोड हटा दिए हैं)

class Emplyee { 
public: 
FullName GetName() const; 
Address GetAddress() const; 
PhoneNumber GetWorkPhone() const; 
... 

bool IsZipCodeValid(Address address); 
... 

private: 
    ... 
} 

स्टीव सोचता है कि बुरा क्या है कि कार्य कम से कम संबंधित हैं। या उसने लिखा है "कर्मचारियों और दिनचर्या के बीच कोई तार्किक संबंध नहीं है जो ज़िप कोड, फोन नंबर या नौकरी वर्गीकरण की जांच करते हैं"

ठीक है, मैं पूरी तरह से उससे सहमत हूं। शायद नीचे दिए गए उदाहरण की तरह कुछ बेहतर है।

class ZipCode 
{ 
public: 
bool IsValid() const; 
    ... 
} 

class Address { 
public: 
    ZipCode GetZipCode() const; 
    ... 
} 

class Employee { 
public: 
Address GetAddress() const; 
    ... 
} 

यह जांचते समय कि ज़िप मान्य है या नहीं, आपको ऐसा कुछ करने की आवश्यकता होगी।

employee.GetAddress().GetZipCode().IsValid(); 

और यह Law of Demeter से संबंधित नहीं है।

तो यदि आप तीनों बिंदुओं में से दो को हटाना चाहते हैं, तो आपको इस तरह प्रतिनिधिमंडल और कुछ रैपर कार्यों का उपयोग करने की आवश्यकता है।

class ZipCode 
{ 
public: 
bool IsValid(); 
} 

class Address { 
public: 
    ZipCode GetZipCode() const; 
    bool IsZipCodeValid() {return GetZipCode()->IsValid()); 
} 

class Employee { 
public: 
FullName GetName() const; 
Address GetAddress() const; 
bool IsZipCodeValid() {return GetAddress()->IsZipCodeValid()); 
PhoneNumber GetWorkPhone() const; 
} 

employee.IsZipCodeValid(); 

लेकिन फिर आपके पास दिनचर्या है जिसमें कोई तार्किक कनेक्शन नहीं है।

मुझे व्यक्तिगत रूप से लगता है कि इस पोस्ट में सभी तीन उदाहरण खराब हैं। क्या यह कोई और तरीका है जिसके बारे में मैंने सोचा नहीं है?

Answer 1

बाद में यह बनाम भुगतान अब भुगतान है।

आप प्रतिनिधिमंडल और रैपर कार्यों को आगे बढ़ा सकते हैं (अब भुगतान करें) और उसके बाद कर्मचारी के अंदरूनी हिस्सों को बदलने में कम काम है। IZZCodeValid() बाद में। या, आप

employee.GetAddress().GetZipCode().IsValid();

लिखकर IsZipCodeValid के माध्यम से सुरंग कर सकते हैं, जहां भी आपको कोड में इसकी आवश्यकता है, लेकिन बाद में भुगतान करना चाहिए कि आप इस श्रेणी को तोड़ने के तरीके में अपनी कक्षा डिज़ाइन को बदलने का निर्णय लेना चाहिए।

आपको अपना जहर चुनना है। ;)

Answer 2

आप तार्किक कनेक्शन याद कर रहे हैं:

class ZipCode 
{ 
public: 
bool IsValid(); 
} 

class Address { 
public: 
    ZipCode GetZipCode() const; 
    bool IsAddressValid(); 
    bool IsValid() {return GetZipCode()->IsValid() && IsAddressValid()); 
} 

class Employee { 
public: 
FullName GetName() const; 
Address GetAddress() const; 
bool IsEmployeeValid(); 
bool IsValid() {return GetAddress()->IseValid() && IsEmployeeValid()); 
PhoneNumber GetWorkPhone() const; 
} 

employee.IsValid(); 

Answer 3

चूंकि कर्मचारी वर्ग और ज़िप-कोड सत्यापन के बीच कोई तार्किक संबंध नहीं है, इसलिए आप ज़िप कोड सत्यापन को पता कक्षा में डाल सकते हैं जहां यह अधिक तर्कसंगत है। फिर आप अपने लिए ज़िप कोड को सत्यापित करने के लिए पता कक्षा से पूछ सकते हैं।

class Address 
{ 
    public: 
     static IsZipValid(ZipCode zip) { return zip.isValid(); } 
}; 

तो फिर तुम

Address::IsZipValid(employee.GetAddress().GetZipCode()); 

मुझे लगता है कि यह तार्किक सहयोग और Demeter के कानून के अपने सीमा के अन्दर संतोषजनक है।