सदस्य कार्य बनाम गणित ऑपरेटरों के लिए गैर-सदस्य कार्य

Question

मैं एक रेखीय बीजगणित पुस्तकालय (लंबी कहानी संक्षेप में लिख रहा हूं, यह एक स्कूल असाइनमेंट है) जिसमें मैट्रिसेस, वैक्टर आदि शामिल हैं। इस पुस्तकालय को बनाने की प्रक्रिया में, मैं उन कार्यों का निर्माण करने जा रहा हूं जो वस्तुओं पर गणितीय कार्य करते हैं। उदाहरण के लिए, मैट्रिक्स को स्थानांतरित करें, मैट्रिक्स को उल्टा करें, वेक्टर को सामान्य करें, आदि।

मैं उत्सुक था कि इस प्रकार के फ़ंक्शन के लिए "सबसे अच्छा अभ्यास" क्या है ... यही है, क्या मुझे फ़ंक्शन को सदस्य फ़ंक्शन या गैर-सदस्य बनाना चाहिए? (स्पष्टता / पुस्तकालय उपयोग के लिए)

उदाहरण:

//Member function way:
B = A.transpose();
C = A.inverse();

//Non-member function way:
B = linalg::transpose(A); //Non-member transpose function in linear algebra namespace
C = linalg::inverse(A);

क्या इन प्रकार के संचालन के बारे में कुछ मानक हैं? या, कम से कम, क्या ऐसा करने का एक आम तरीका है? मैं पहले विकल्प की ओर झुक रहा हूं, लेकिन मैं जानना चाहता हूं कि क्या यह अनुशंसित है।

Answer 1

यह सिर्फ स्टाइल और स्वाद का मामला है। मैंने अलग-अलग रैखिक बीजगणित पुस्तकालय देखे हैं

• सदस्य कार्यों का उपयोग करते हुए एक OOP शैली में लिखा गया है

• एक गैर-ओओपी शैली में केवल मुफ्त कार्यों का उपयोग करके लिखा गया है

• दोनों के साथ एक एपीआई प्रदान करना

और वे सभी काम कर रहे थे। कम से कम, आपका एपीआई संगत होना चाहिए, इसलिए अपनी पसंद चुनें और सुनिश्चित करें कि आप उन शैलियों को मनमाने ढंग से नहीं मिलाते हैं।

Answer 2

सदस्यता शुल्क से बचें: जहाँ संभव हो, फ़ंक्शंस को गैर-मित्रवत मित्र बनाना पसंद करें।

नॉनमेम्बर नॉनफ्रेंड फ़ंक्शंस निर्भरता को कम करके एनकैप्सुलेशन में सुधार करते हैं: फ़ंक्शन का शरीर कक्षा के गैर-गणमान्य सदस्यों पर निर्भर होने के लिए नहीं आ सकता है (देखें आइटम 11)। वे अलग करने योग्य कार्यक्षमता को मुक्त करने के लिए अखंड वर्गों को तोड़ते हैं, आगे युग्मन को कम करते हैं (देखें आइटम 33)। वे उदारता में सुधार करते हैं, क्योंकि ऐसे टेम्प्लेट लिखना कठिन होता है जो यह नहीं जानते कि ऑपरेशन किसी दिए गए प्रकार के लिए सदस्य है या नहीं [...]

जड़ी बूटी वाला

Comments

अंत में एक अच्छा जवाब: देर से, लेकिन बहुत देर से नहीं। : एक अन्य संदर्भ ;-) GotW # 84: Monoliths "खुला"

— Deduplicator

Answer 3

सदस्य और गैर-सदस्य दोनों कार्यों में केवल स्वाद के अलावा वास्तविक फायदे हैं। उदाहरण के लिए, एक matrixवर्ग को लागू करने के लिए उपयोग किए जाने वाले अंतर्निहित सरणी (ओं) संभवतः होंगे private, इसलिए, आपको friendतब तक उपयोग करना होगा जब तक आप सदस्य कार्यों का उपयोग नहीं करते हैं। इस संबंध में, एक ओओ डिजाइन बेहतर हो सकता है।

हालांकि, यह ध्यान रखें कि, समय-समय पर कंप्यूटर वैज्ञानिकों को जटिल गणित के फार्मूले को लागू करना होता है, बिना यह जाने कि आपका वास्तव में क्या है। जब मुझे ऐसा करना होता है, तो मैं गैर-सदस्य कार्यों को प्राथमिकता देता हूं क्योंकि "दृश्य" परिणाम मूल गणित सूत्र के करीब होगा (चूंकि गणित सूत्र आमतौर पर एक कार्यात्मक शैली का उपयोग करता है)।

अंत में, जवाब डॉक ब्राउन के एक के समान है: यह स्वाद की बात है। संक्षेप में, आप सदस्य कार्यों के साथ एक ओओ-शैली पुस्तकालय लिखने पर विचार कर सकते हैं (लिखने में आसान, नहीं friend), फिर गैर-सदस्य कार्यों को लिखने के लिए वही कार्य करें जो सदस्य सदस्यों के लिए अपने तर्क को आगे बढ़ाएंगे। यह आपको सुसंगत रहने देता है और उपयोगकर्ता को वह चुनने देता है जो वह सोचता है कि सबसे अच्छा है।

Answer 4

यदि आप अपने समस्या कथन में गहराई से डूबते हैं, तो यह स्पष्ट है कि कुछ बिंदु पर आप कस्टम डेटा संरचनाओं का उपयोग करेंगे जो कुछ गणितीय संस्थाओं का प्रतिनिधित्व करते हैं। उदाहरण के लिए, आप एक मैट्रिक्स को n- आयामी सरणी के मेरे साधन का प्रतिनिधित्व कर सकते हैं। अपने उदाहरण पर विस्तार से बताने के लिए,

// C way
typedef struct {
    int data[MAX_LEN][MAX_LEN];
} MATRIX;

MATRIX B = transpose(A);

// C++ way
class Matrix; // Forward Declaration
class Matrix {
    int data[MAX_LEN][MAX_LEN];
    public:
        Matrix transpose();
};

Matrix B = A.transpose();

(C ++ का उदाहरण सरल है, आप टेम्प्लेट और इस तरह का उपयोग कर सकते हैं।)

विचार करने के लिए बिंदु दोनों मामलों में कस्टम डेटा संरचनाओं का उपयोग करने में आसानी है। C ++ (या कोई भी ऑब्जेक्ट ओरिएंटेड) एक भाषा के रूप में अपने आप में अधिक शक्तिशाली है, और यह लाइब्रेरी के उपभोक्ता तक फैली हुई है जितना कि यह कार्यान्वयनकर्ता को लाभ पहुंचाता है। मैंने अतीत में केवल पुस्तकालयों का उपयोग किया है और उन कस्टम डेटा संरचनाओं को कुछ ही समय में सभी जगह मिल रहा है! जबकि इंटरऑपरेबिलिटी बाद के साथ हासिल करना आसान है (विशेष निर्माणकर्ताओं का उपयोग करके, शायद?)

इसे हवा देने के लिए, यदि आप C ++ का उपयोग कर रहे हैं, तो एक वस्तु उन्मुख दृष्टिकोण निश्चित रूप से अनुशंसित है।

Comments

क्षमा करें, आपके तर्क में बहुत कम ठोस तथ्य है। आपके दो transposeउदाहरणों के बीच उपयोग में आसानी में कोई अंतर नहीं है । मुख्य कारण C ++ यानी आसान है क्योंकि कॉपी और असाइनमेंट शब्दार्थ वास्तव में काम करते हैं। A = BC में संकलित कर सकता है लेकिन शायद गलत काम करता है।

— एमएसएल

कॉपी शब्दार्थों के लिए +1 मैं जिस बिंदु को प्राप्त करने की कोशिश कर रहा था, वह वस्तुओं ("अभ्यावेदन" पर एनकैप्सुलेशन) का उपयोग कर रहा है, संरचनाओं और संबंधित कार्यों के शिथिल युग्मित सेट का उपयोग करके।

— डॉटबगफिक्स