क्या यह पीआईएमपीएल पैटर्न का उपयोग करने के लिए एक अच्छी जगह है?

Question

मैं एक पुस्तकालय पर काम कर रहा हूं जो कुछ सेवा के लिए क्लाइंट इंटरफेस को परिभाषित करता है। हुड के तहत मुझे उपयोगकर्ताओं द्वारा प्रदान किए गए आंकड़ों को प्रमाणित करना होगा और फिर इसे किसी अन्य लाइब्रेरी से कनेक्शन क्लास का उपयोग करके "इंजन" प्रक्रिया में पास करना होगा (नोट: कनेक्शन क्लास हमारी लाइब्रेरी के उपयोगकर्ताओं के लिए ज्ञात नहीं है)। मेरे साथियों में से एक pimpl उपयोग का प्रस्ताव रखा:

class Client { 
public: 
    Client(); 
    void sendStuff(const Stuff &stuff) {_pimpl->sendStuff(stuff);} 
    Stuff getStuff(const StuffId &id) {return _pimpl->getStuff(id);} 
private: 
    ClientImpl *_pimpl; 
} 

class ClientImpl { // not exported 
public: 
    void sendStuff(const Stuff &stuff); 
    Stuff getStuff(const StuffId &id); 
private: 
    Connection _connection; 
} 

हालांकि, मैं यह परीक्षण करने के लिए बहुत मुश्किल - भले ही मैं कनेक्शन के कुछ मज़ाक उड़ाया कार्यान्वयन करने के लिए अपने परीक्षण लिंक, मैं स्थापित करने के लिए यह करने के लिए आसान पहुँच नहीं है और अपेक्षाओं को मान्य करें। मैं कुछ याद आ रही है, या अधिक स्वच्छ और परीक्षण योग्य समाधान इंटरफेस + कारखाना उपयोग कर रहा है:

class ClientInterface { 
public: 
    void sendStuff(const Stuff &stuff) = 0; 
    Stuff getStuff(const StuffId &id) = 0; 
} 

class ClientImplementation : public ClientInterface { // not exported 
public: 
    ClientImplementation(Connection *connection); 
    // +implementation of ClientInterface 
} 

class ClientFactory { 
    static ClientInterface *create(); 
} 

वहाँ कोई कारण इस स्थिति में pimpl साथ जाने के लिए कर रहे हैं?

Answer 1

GoTW15

GoTW28

हर्ब Sutter से। आपको शुरू करने के लिए अच्छे संकेतक।

Answer 2

AFAIK Pimpl idiom का उपयोग करने का सामान्य कारण वर्ग के कार्यान्वयन के लिए संकलन/लिंक समय निर्भरताओं को कम करना है (सार्वजनिक हेडर फ़ाइल से कार्यान्वयन विवरण को हटाकर)। एक अन्य कारण कक्षा को अपने व्यवहार को गतिशील रूप से बदलने में सक्षम होना चाहिए (उर्फ State pattern)।

दूसरा ऐसा मामला प्रतीत नहीं होता है, और पहला विरासत + कारखाने के साथ भी हासिल किया जा सकता है। हालांकि, जैसा कि आपने नोट किया है, बाद वाला समाधान इकाई परीक्षण के लिए बहुत आसान है, इसलिए मैं इसे पसंद करूंगा।

Answer 3

हां यह पिंपल पैटर्न का उपयोग करने के लिए एक अच्छी जगह है, और हाँ यह परीक्षण करना मुश्किल होगा।

• Pimpl ग्राहक से निर्भरता छुपा के बारे में है:

  समस्या यह है कि दो अवधारणाओं को एक-दूसरे का विरोध करते है इस संकलन/लिंक समय कम कर देता है और देखने का एक ABI स्थिरता बिंदु से बेहतर है।

• यूनिट टेस्टिंग निर्भरता में शल्य चिकित्सा हस्तक्षेप (नकली अप के उपयोग, उदाहरण के लिए)

हालांकि, इसका मतलब यह नहीं कि आप किसी अन्य के लिए एक बलिदान चाहिए के बारे में आम तौर पर है। इसका मतलब केवल आपको अपना कोड अनुकूलित करना चाहिए।

अब, Connection को उसी मुहावरे के साथ लागू किया गया था तो क्या होगा?

class Connection 
{ 
private: 
    ConnectionImpl* mImpl; 
}; 

और एक फैक्टरी के माध्यम से दिया:

// Production code: 

Client client = factory.GetClient(); 

// Test code: 
MyTestConnectionImpl impl; 
Client client = factory.GetClient(impl); 

इस तरह, आप जुओं से भरा हुआ किरकिरा अपने परीक्षण के विवरण कनेक्शन के लागू ग्राहक के लिए कार्यान्वयन उजागर या तोड़ने ABI बिना ग्राहक का परीक्षण करते समय उपयोग कर सकते हैं ।