वर्ग जो किसी भी चीज़ का प्रतिनिधित्व नहीं करता है

42

मैं सिर्फ अपने आवेदन को डिजाइन कर रहा हूं और मुझे यकीन नहीं है कि मैं एसओएलआईडी और ओओपी को सही ढंग से समझता हूं। कक्षाओं को 1 काम करना चाहिए और इसे अच्छी तरह से करना चाहिए लेकिन दूसरी ओर से उन्हें वास्तविक वस्तुओं का प्रतिनिधित्व करना चाहिए जिनके साथ हम काम करते हैं।

मेरे मामले में मैं एक डाटासेट पर एक सुविधा निष्कर्षण करता हूं और फिर मैं एक मशीन सीखने का विश्लेषण करता हूं। मुझे लगता है कि मैं तीन कक्षाएं बना सकता हूं

FeatureExtractor
डेटासेट
विश्लेषक

लेकिन FeatureExtractor वर्ग कुछ भी प्रतिनिधित्व नहीं करता है, यह कुछ ऐसा करता है जो इसे एक वर्ग की तुलना में अधिक दिनचर्या बनाता है। इसका सिर्फ एक फ़ंक्शन होगा जिसका उपयोग किया जाएगा: extract_features ()

क्या यह उन वर्गों को बनाने के लिए सही है जो एक चीज का प्रतिनिधित्व नहीं करते हैं लेकिन एक चीज करते हैं?

संपादित करें: निश्चित नहीं है कि यह मायने रखता है लेकिन मैं पायथन का उपयोग कर रहा हूं

और अगर extract_features () उस तरह दिखाई देगा: क्या उस पद्धति को रखने के लिए एक विशेष वर्ग बनाने के लायक है?

def extract_features(df):
    extr = PhrasesExtractor()
    extr.build_vocabulary(df["Text"].tolist())

    sent = SentimentAnalyser()
    sent.load()

    df = add_features(df, extr.features)
    df = mark_features(df, extr.extract_features)
    df = drop_infrequent_features(df)
    df = another_processing1(df)
    df = another_processing2(df)
    df = another_processing3(df)
    df = set_sentiment(df, sent.get_sentiment)
    return df

object-oriented object-oriented-design solid

— एलिकजा गोलोवका
स्रोत

13

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

— बरगी

31

ज्ञात हो कि पायथन में नॉन-ओओ दृष्टिकोण का उपयोग करना काफी सामान्य और स्वीकार्य है।

— jpmc26

13

आपको डोमेन ड्रिवेन डिज़ाइन में रुचि हो सकती है। "कक्षाओं को वास्तविक दुनिया से वस्तुओं का प्रतिनिधित्व करना चाहिए" वास्तव में गलत है ... उन्हें डोमेन में वस्तुओं का प्रतिनिधित्व करना चाहिए । डोमेन को अक्सर वास्तविक दुनिया से दृढ़ता से जोड़ा जाता है, लेकिन अनुप्रयोग के आधार पर कुछ चीजें ऑब्जेक्ट्स या नहीं मानी जा सकती हैं, या कुछ चीजें जो "वास्तव में" अलग होती हैं, वे आवेदन के डोमेन के अंदर या तो जुड़े या समान हो सकती हैं।

— बाकूरी

1

जैसा कि आप ओओपी से अधिक परिचित हो गए हैं, मुझे लगता है कि आप पाएंगे कि कक्षाएं बहुत कम ही वास्तविक दुनिया की संस्थाओं के साथ एक-से-एक अनुरूप हैं। उदाहरण के लिए, यहाँ एक निबंध कि सभी एक ही कक्षा में एक वास्तविक दुनिया इकाई के साथ जुड़े कार्यक्षमता रटना करने की कोशिश कर का तर्क है बहुत बार एक विरोधी पैटर्न है: programmer.97things.oreilly.com/wiki/index.php/...

— केविन - मोनिका

1

"हमें उन वास्तविक वस्तुओं का प्रतिनिधित्व करना चाहिए जिनके साथ हम काम करते हैं।" जरुरी नहीं। बहुत सी भाषाओं में बाइट्स की एक धारा का प्रतिनिधित्व करने वाला एक स्ट्रीम क्लास होता है, जो एक 'वास्तविक वस्तु' के बजाय एक अमूर्त अवधारणा है। तकनीकी रूप से एक फाइल सिस्टम 'वास्तविक वस्तु' नहीं है, यह सिर्फ एक अवधारणा है, लेकिन कभी-कभी एक फ़ाइल सिस्टम या इसके एक हिस्से का प्रतिनिधित्व करने वाली कक्षाएं होती हैं।

— फाप्र्स

96

कक्षाओं को 1 काम करना चाहिए और इसे अच्छी तरह से करना चाहिए

हां, यह आम तौर पर एक अच्छा तरीका है।

लेकिन दूसरी ओर से उन्हें उस वास्तविक वस्तु का प्रतिनिधित्व करना चाहिए जिसके साथ हम काम करते हैं।

नहीं, वह एक IMHO आम गलतफहमी है। OOP के लिए एक अच्छे शुरुआतकर्ता की पहुंच अक्सर "वास्तविक दुनिया से चीजों का प्रतिनिधित्व करने वाली वस्तुओं के साथ शुरू होती है" , यह सच है।

हालाँकि, आपको इसके साथ नहीं रुकना चाहिए !

विभिन्न तरीकों से आपके कार्यक्रम को तैयार करने के लिए कक्षाएं (और चाहिए) का उपयोग किया जाना चाहिए। वास्तविक दुनिया से वस्तुओं की मॉडलिंग इस का एक पहलू है, लेकिन केवल एक ही नहीं है। किसी विशिष्ट कार्य के लिए मॉड्यूल या घटक बनाना कक्षाओं के लिए एक और समझदार उपयोग मामला है। एक "फीचर एक्सट्रैक्टर" शायद ऐसा एक मॉड्यूल है, और यहां तक कि इसमें केवल एक सार्वजनिक विधि शामिल है extract_features(), मुझे आश्चर्य होगा कि अगर बहुत सारे निजी तरीके शामिल नहीं हैं और शायद कुछ साझा राज्य। तो एक वर्ग होने से FeatureExtractorइन निजी तरीकों के लिए एक प्राकृतिक स्थान मिल जाएगा।

साइड नोट: पायथन जैसी भाषाओं में जो एक अलग मॉड्यूल अवधारणा का समर्थन करते हैं, एक भी इसके लिए एक मॉड्यूल का उपयोग कर सकता है FeatureExtractor, लेकिन इस प्रश्न के संदर्भ में, यह आईएमएचओ एक नगण्य अंतर है।

इसके अलावा, एक "फीचर एक्सट्रैक्टर" की कल्पना "एक व्यक्ति या बॉट जो सुविधाओं को निकालता है" के रूप में की जा सकती है। यह एक अमूर्त "बात" है, हो सकता है कि कोई चीज़ आपको वास्तविक दुनिया में न मिले, लेकिन नाम ही एक उपयोगी अमूर्तता है, जो सभी को इस बात की धारणा देता है कि उस वर्ग की ज़िम्मेदारी क्या है। इसलिए मैं असहमत हूं कि यह वर्ग "किसी भी चीज़ का प्रतिनिधित्व नहीं करता है"।

— डॉक्टर ब्राउन
स्रोत

33

मुझे विशेष रूप से पसंद है कि आपने आंतरिक राज्य के मुद्दे का उल्लेख किया है। मुझे अक्सर लगता है कि मैं पायथन में एक वर्ग या एक समारोह में कुछ बनाने के लिए निर्णय लेने वाला कारक हूं।

— डेविड जेड

17

आप "क्लासाइटिस" की सलाह देते हैं। इसके लिए एक वर्ग न बनाएं, यह एक जावा-शैली एंटीपैटर्न है। यदि यह एक फंक्शन है, तो इसे फंक्शन करें। आंतरिक स्थिति अप्रासंगिक है: कार्यों में (बंद होने के माध्यम से) हो सकता है।

— कोनराड रुडोल्फ

25

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

— Doc Brown

8

@DocBrown मैं असहमत हूँ। यह एक सार्वजनिक पद्धति वाला एक वर्ग है। एपीआई बुद्धिमान, कि एक समारोह से अप्रभेद्य है। विवरण के लिए मेरा उत्तर देखें। यदि आपको किसी राज्य का प्रतिनिधित्व करने के लिए एक विशिष्ट प्रकार बनाने की आवश्यकता है, तो एकल-विधि कक्षाओं का उपयोग करना उचित हो सकता है । लेकिन यहाँ ऐसा नहीं है (और फिर भी, फ़ंक्शन का उपयोग कभी-कभी किया जा सकता है)।

— कोनराड रुडोल्फ

6

@DocBrown मैं देखना शुरू कर रहा हूं कि आपका क्या मतलब है: आप उन कार्यों के बारे में बात कर रहे हैं जो अंदर से कहे जाते हैं extract_features? मैंने केवल यह माना कि वे दूसरी जगह से सार्वजनिक कार्य थे। पर्याप्त रूप से, मैं सहमत हूं कि यदि ये निजी हैं तो उन्हें संभवतः एक मॉड्यूल में जाना चाहिए (लेकिन अभी भी: एक वर्ग नहीं , जब तक कि वे राज्य साझा नहीं करते हैं), एक साथ extract_features। (उस ने कहा, आप निश्चित रूप से उन्हें उस समारोह के अंदर स्थानीय रूप से घोषित कर सकते हैं।)

— कोनराड रूडोल्फ

44

डॉक्टर ब्राउन स्पॉट-ऑन हैं: कक्षाओं को वास्तविक दुनिया की वस्तुओं का प्रतिनिधित्व करने की आवश्यकता नहीं है। उन्हें बस उपयोगी होने की जरूरत है । कक्षाएं मौलिक रूप से केवल अतिरिक्त प्रकार हैं, और वास्तविक दुनिया में क्या करता है intया stringमेल खाता है? वे अमूर्त वर्णन हैं, ठोस नहीं, ठोस चीजें हैं।

उन्होंने कहा, आपका मामला विशेष है। आपके विवरण के अनुसार:

और अगर extract_features () उस तरह दिखाई देगा: क्या उस पद्धति को रखने के लिए एक विशेष वर्ग बनाने के लायक है?

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

कक्षाओं का अति प्रयोग इस तथ्य के कारण है कि 1990 के दशक में OOP जावा के साथ मुख्यधारा बन गया। दुर्भाग्य से उस समय जावा में कई आधुनिक भाषा सुविधाओं (जैसे क्लोजर) का अभाव था, जिसका अर्थ है कि कई अवधारणाएं कक्षाओं के उपयोग के बिना व्यक्त करना कठिन या असंभव था। उदाहरण के लिए, जावा में यह असंभव था कि हाल ही में राज्य (यानी क्लोजर) करने वाले तरीके हैं। इसके बजाय, आपको राज्य को ले जाने के लिए एक वर्ग लिखना था, और जिसने एक एकल विधि (कुछ ऐसा कहा जाता है invoke) को उजागर किया ।

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

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

— कोनराड रुडोल्फ
स्रोत

यह जोड़ना उपयोगी होगा कि यदि उदाहरण में कहे गए कार्य वास्तव में निजी कार्य हैं, तो उन्हें मॉड्यूल या कक्षा में एनकैप्सुलेट करना पूरी तरह से उचित होगा। अन्यथा, मैं पूरी तरह से सहमत हूं।

— लेलियल

11

यह भी याद रखने के लिए उपयोगी है कि "ओओपी" का अर्थ "कक्षाओं का एक गुच्छा" नहीं है। कार्य पायथन में ऑब्जेक्ट हैं, इसलिए इसे "ओओपी नहीं" के रूप में विचार करने की आवश्यकता नहीं है। दरअसल, यह बस है पुन: उपयोग में निर्मित प्रकार / वर्गों, और "पुन: उपयोग" प्रोग्रामिंग में पवित्र grails से एक है। एक कक्षा में इसे लपेटने से पुन: उपयोग को रोका जा सकेगा, क्योंकि इस नए एपीआई के साथ कुछ भी संगत नहीं होगा (जब तक __call__कि परिभाषित नहीं किया जाता है, जिस स्थिति में बस एक फ़ंक्शन का उपयोग करें!)

— Warbo

3

"वर्गों बनाम मुक्त-स्थायी कार्यों" के विषय पर भी: eev.ee/blog/2013/03/03/…

— जोकर_vD

1

क्या यह मामला नहीं है, हालांकि पायथन में "फ्री-फ़ंक्शंस" भी एक प्रकार के ऑब्जेक्ट हैं जो एक विधि को उजागर करते हैं __call__()? क्या यह वास्तव में एक अनाम आंतरिक वर्ग के उदाहरण से अलग है? सिंथेटिक रूप से, निश्चित रूप से, लेकिन एक भाषा डिजाइन से, यह आपके द्वारा यहां पेश किए जाने से कम महत्वपूर्ण अंतर जैसा लगता है।

— जिम्मीजम्स

1

@ जिम्मीजैम राइट पूरे बिंदु यह है कि वे विशिष्ट उद्देश्य के लिए समान कार्यक्षमता प्रदान करते हैं लेकिन उपयोग करने के लिए सरल हैं।

— कोनराड रुडोल्फ

36

मैं सिर्फ अपने आवेदन को डिजाइन कर रहा हूं और मुझे यकीन नहीं है कि मैं एसओएलआईडी और ओओपी को सही ढंग से समझता हूं।

इस पर 20 साल से अधिक रहा और मुझे यकीन नहीं है।

कक्षाओं को 1 काम करना चाहिए और इसे अच्छी तरह से करना चाहिए

यहां गलत करना मुश्किल है।

हमें उन वास्तविक वस्तुओं का प्रतिनिधित्व करना चाहिए जिनके साथ हम काम करते हैं।

क्या सचमे? मुझे हर समय का सबसे लोकप्रिय और सफल वर्ग को लागू करते हैं: String। हम इसका उपयोग पाठ के लिए करते हैं। और वास्तविक विश्व वस्तु जिसका प्रतिनिधित्व करता है वह यह है:

क्यों नहीं, सभी प्रोग्रामर मछली पकड़ने के प्रति जुनूनी नहीं हैं। यहाँ हम एक रूपक नामक चीज़ का उपयोग कर रहे हैं। यह उन चीजों के मॉडल बनाने के लिए ठीक है जो वास्तव में मौजूद नहीं हैं। यह विचार है जो स्पष्ट होना चाहिए। आप अपने पाठकों के मन में चित्र बना रहे हैं। उन छवियों को वास्तविक होना जरूरी नहीं है। बस आसानी से समझ में आ गया।

डेटा (स्थिति) के आसपास एक अच्छा OOP डिज़ाइन क्लस्टर संदेश (विधियाँ) बनाता है ताकि उन संदेशों की प्रतिक्रियाएँ उस डेटा के आधार पर भिन्न हो सकें। अगर वह मॉडल कुछ असली दुनिया की बात कर रहा है, तो बहुत मुश्किल है। यदि नहीं, तो ठीक है। इसलिए जब तक यह पाठक को समझ में आता है, यह ठीक है।

अब यकीन है, आप इसे इस तरह से सोच सकते हैं:

लेकिन अगर आपको लगता है कि यह वास्तविक दुनिया में मौजूद है इससे पहले कि आप रूपक का उपयोग कर सकें, तो आपके प्रोग्रामिंग कैरियर में बहुत सारी कला और शिल्प शामिल हैं।

— candied_orange
स्रोत

1

चित्रों की एक बहुत ही

— कड़ी

इस बिंदु पर मुझे यकीन नहीं है कि "स्ट्रिंग" रूपक भी है। यह सिर्फ एक विशिष्ट प्रोग्रामिंग डोमेन अर्थ है, के रूप में जैसे शब्दों करना classऔर tableऔर column...

— Kyralessa

@Kyralessa आप ईथर नौसिखिया रूपक सिखाने के लिए या आप इसे उनके लिए जादू हो। कृपया मुझे जादू से विश्वास करने वाले कोडर्स से बचाएं।

— कैंडिड_ओरेंज

6

सावधान रहें! कहीं भी SOLID का कहना है कि एक वर्ग को केवल "एक काम करना चाहिए"। अगर ऐसा होता, तो कक्षाएं केवल एक ही विधि होतीं, और वास्तव में कक्षाओं और कार्यों के बीच अंतर नहीं होता।

SOLID का कहना है कि एक वर्ग को एक ही जिम्मेदारी का प्रतिनिधित्व करना चाहिए । ये एक टीम में व्यक्तियों की ज़िम्मेदारियों की तरह हैं: चालक, वकील, पिकपॉकेट, ग्राफिक डिजाइनर आदि। इनमें से प्रत्येक व्यक्ति कई (संबंधित) कार्य कर सकता है, लेकिन सभी एक ही जिम्मेदारी से संबंधित हैं।

इसका मुद्दा यह है - यदि आवश्यकताओं में बदलाव होता है, तो आपको आदर्श रूप से केवल एक वर्ग को संशोधित करना होगा। यह कोड को समझने में आसान बनाता है, संशोधित करना आसान है और जोखिम को कम करता है।

ऐसा कोई नियम नहीं है कि कोई वस्तु "वास्तविक वस्तु" का प्रतिनिधित्व करे। यह सिर्फ कार्गो-पंथ विद्या है क्योंकि ओओ को शुरू में सिमुलेशन में उपयोग के लिए आविष्कार किया गया था । लेकिन आपका कार्यक्रम सिमुलेशन नहीं है (कुछ आधुनिक OO अनुप्रयोग है), इसलिए यह नियम लागू नहीं होता है। जब तक प्रत्येक वर्ग की एक अच्छी तरह से परिभाषित जिम्मेदारी है, तब तक आपको ठीक होना चाहिए।

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

— JacquesB
स्रोत

+1 के लिए "यदि आप इसे किसी फ़ंक्शन के साथ हल कर सकते हैं तो एक वर्ग बनाने की आवश्यकता नहीं है"। कभी-कभी किसी को सच बोलने की जरूरत होती है।

— tchrist

5

क्या यह उन वर्गों को बनाने के लिए सही है जो एक चीज का प्रतिनिधित्व नहीं करते हैं लेकिन एक चीज करते हैं?

सामान्य तौर पर यह ठीक है।

थोड़ा और अधिक विशिष्ट विवरण के बिना FeatureExtractorकक्षा को वास्तव में क्या करना चाहिए, यह बताना मुश्किल है।

वैसे भी, भले ही FeatureExtractorकेवल एक सार्वजनिक extract_features()समारोह को उजागर करता है, मैं इसे एक Strategyवर्ग के साथ कॉन्फ़िगर करने के बारे में सोच सकता था , जो निर्धारित करता है कि वास्तव में निष्कर्षण कैसे किया जाना चाहिए।

एक अन्य उदाहरण एक टेम्पलेट फ़ंक्शन के साथ एक वर्ग है ।

और अधिक व्यवहार डिजाइन पैटर्न हैं , जो वर्ग मॉडल पर आधारित हैं।

जैसा कि आपने स्पष्टीकरण के लिए कुछ कोड जोड़ा है।

और अगर extract_features () उस तरह दिखाई देगा: क्या उस पद्धति को रखने के लिए एक विशेष वर्ग बनाने के लायक है?

रेखा

 sent = SentimentAnalyser()

वास्तव में मेरा क्या मतलब है कि आप एक रणनीति के साथ एक वर्ग को कॉन्फ़िगर कर सकते हैं ।

यदि आपके पास उस SentimentAnalyserवर्ग के लिए एक इंटरफ़ेस है , तो आप इसे FeatureExtractorअपने कार्य में उस विशिष्ट कार्यान्वयन के लिए सीधे युग्मन के बजाय, निर्माण के अपने बिंदु पर कक्षा में पास कर सकते हैं ।

— ῥεῖνῥεῖα ῥεῖ
स्रोत

2

मुझे जटिलता (एक FeatureExtractorवर्ग) जोड़ने का कोई कारण नहीं दिखता है , और भी अधिक जटिलता ( SentimentAnalyserवर्ग के लिए एक अंतरफलक) का परिचय देने के लिए । यदि डिकूपिंग वांछनीय है, तो फ़ंक्शन को एक तर्क के रूप में extract_featuresले सकता get_sentimentहै ( loadकॉल फ़ंक्शन से स्वतंत्र लगता है और केवल इसके प्रभावों के लिए कहा जाता है)। यह भी ध्यान दें कि पायथन में इंटरफेस नहीं हैं / प्रोत्साहित करते हैं।

— वारबो

1

@warbo - भले ही आप फ़ंक्शन को एक तर्क के रूप में आपूर्ति करते हैं, इसे एक फ़ंक्शन बनाकर, आप संभावित कार्यान्वयन को प्रतिबंधित करते हैं जो कि एक फ़ंक्शन के प्रारूप में फिट होंगे, लेकिन अगर एक आह्वान और एक के बीच लगातार राज्य का प्रबंधन करने की आवश्यकता है अगले (जैसे एक CacheingFeatureExtractorया एक TimeSeriesDependentFeatureExtractor) तो एक वस्तु एक बेहतर फिट होगा। एक वस्तु की आवश्यकता नहीं है सिर्फ इसलिए कि वहाँ वर्तमान में वहाँ मतलब यह नहीं है कभी नहीं होगा।

— जूल्स

3

@ जूल्स सबसे पहले आपको इसकी आवश्यकता नहीं है (YAGNI), दूसरी बात पायथन फ़ंक्शंस लगातार स्टेट (क्लोजर) को संदर्भित कर सकते हैं यदि आपको इसकी आवश्यकता है (आप नहीं जा रहे हैं), तो तीसरे फ़ंक्शन के उपयोग से किसी भी वस्तु के साथ किसी भी चीज़ को प्रतिबंधित नहीं किया जाता है __call__यदि आपको इसकी आवश्यकता है, तो विधि संगत होगी (चौथा नहीं), चौथा एक आवरण जोड़कर, जैसे FeatureExtractorआप कोड को कभी भी लिखे गए अन्य सभी कोड के साथ असंगत बना रहे हैं (जब तक कि आप एक __call__विधि प्रदान नहीं करते हैं , जिस स्थिति में एक फ़ंक्शन स्पष्ट रूप से सरल हो जाएगा )

— वारबो

0

पैटर्न और सभी फैंसी भाषा / अवधारणाएं एक तरफ: जो आपने भर में ठोकर खाई है वह एक नौकरी या एक बैच प्रक्रिया है ।

दिन के अंत में, यहां तक कि एक शुद्ध ओओपी कार्यक्रम को किसी न किसी तरह से संचालित करने की आवश्यकता होती है, वास्तव में काम करने के लिए; किसी भी तरह एक प्रवेश बिंदु होना चाहिए। उदाहरण के लिए, MVC पैटर्न में, "C" ontroller GUI से क्लिक आदि ईवेंट प्राप्त करता है और फिर अन्य घटकों को ऑर्केस्ट्रेट करता है। क्लासिक कमांड लाइन टूल में, एक "मुख्य" फ़ंक्शन ऐसा ही करेगा।

क्या यह उन वर्गों को बनाने के लिए सही है जो एक चीज का प्रतिनिधित्व नहीं करते हैं लेकिन एक चीज करते हैं?

आपकी कक्षा एक ऐसी इकाई का प्रतिनिधित्व करती है जो कुछ करती है और बाकी सब कुछ ऑर्केस्ट्रा करती है। आप इसे कंट्रोलर , जॉब , मेन या जो भी मन में आए उसे नाम दे सकते हैं।

और अगर extract_features () उस तरह दिखाई देगा: क्या उस पद्धति को रखने के लिए एक विशेष वर्ग बनाने के लायक है?

यह परिस्थितियों पर निर्भर करता है (और मैं पाइथन में किए गए सामान्य तरीके से परिचित नहीं हूं)। यदि यह सिर्फ एक छोटा-शॉट कमांड लाइन टूल है, तो क्लास के बजाय एक विधि ठीक होनी चाहिए। आपके कार्यक्रम का पहला संस्करण एक विधि के साथ दूर हो सकता है, निश्चित रूप से। यदि, बाद में, आप पाते हैं कि आप दर्जनों ऐसे तरीकों से समाप्त होते हैं, शायद वैश्विक चर के साथ भी मिलाया जाता है, तो यह कक्षाओं में सुधार करने का समय है।

— AnoE
स्रोत

3

ध्यान दें कि इस तरह के परिदृश्यों में, स्टैंडअलोन प्रक्रियाओं को "विधियों" को कॉल करना भ्रामक हो सकता है। पायथन सहित अधिकांश भाषाएं उन्हें "फ़ंक्शन" कहती हैं। "विधियाँ" फ़ंक्शंस / प्रक्रियाएँ हैं जो एक वर्ग के एक विशेष उदाहरण के लिए बाध्य होती हैं, जो आपके शब्द के उपयोग के विपरीत है :)

— वारबो

सच है, @Warbo। या हम उन्हें प्रक्रिया या अशुद्ध या उप या ... कह सकते हैं; और वे एक उदाहरण से संबंधित वर्ग विधियां (एसआईसी) हो सकती हैं। मुझे आशा है कि कोमल पाठक अभीष्ट अर्थ को दूर कर सकेगा। :)

— AnoE

@ पता है कि अच्छा है! अधिकांश शिक्षण सामग्री मैंने बताई है कि शब्द और विधि परस्पर विनिमय योग्य हैं, और यह केवल एक भाषा-निर्भर प्राथमिकता है।

— डोम

@ सामान्य में ("शुद्ध") "फ़ंक्शन" इनपुट मानों से आउटपुट मानों तक मैपिंग है; एक "प्रक्रिया" एक फ़ंक्शन है जो प्रभाव भी पैदा कर सकता है (जैसे फ़ाइल को हटाना); दोनों स्टेटिकली डिस्पैच किए गए हैं (यानी लेक्सिकल स्कोप में देखे गए हैं)। एक "विधि" एक फ़ंक्शन या (आमतौर पर) प्रक्रिया है जो गतिशील रूप से एक मूल्य ("ऑब्जेक्ट" कहा जाता है) से भेजा जाता है, जो स्वचालित रूप से विधि के एक (अंतर्निहित thisया स्पष्ट self) तर्क से बंधा होता है । एक ऑब्जेक्ट के तरीके परस्पर "खुले तौर पर" पुनरावर्ती हैं, इसलिए इस प्रतिस्थापन का उपयोग करने के लिए fooसभी self.fooकॉलों को बदलने का कारण बनता है ।

— वारबो

0

हम के रूप में OOP के बारे में सोच सकते हैं मॉडलिंग एक प्रणाली के व्यवहार। ध्यान दें कि सिस्टम को 'वास्तविक दुनिया' में मौजूद नहीं होना है, हालांकि वास्तविक दुनिया के रूपक कभी-कभी उपयोगी हो सकते हैं (जैसे "पाइपलाइन", "कारखाने", आदि)।

यदि हमारा वांछित सिस्टम एक साथ सभी मॉडल के लिए बहुत जटिल है, तो हम इसे छोटे टुकड़ों में तोड़ सकते हैं और उन ("समस्या डोमेन") को मॉडल कर सकते हैं, जिनमें आगे टूटना शामिल हो सकता है, और तब तक जब तक हम उन टुकड़ों तक नहीं पहुंच जाते जिनके व्यवहार से मेल खाता है (कम या ज्यादा) कुछ बिल्ट-इन लैंग्वेज ऑब्जेक्ट जैसे नंबर, एक स्ट्रिंग, एक सूची इत्यादि।

एक बार जब हमारे पास वे सरल टुकड़े हो जाते हैं, तो हम उन्हें बड़े टुकड़ों के व्यवहार का वर्णन करने के लिए एक साथ जोड़ सकते हैं, जिसे हम एक साथ मिलकर और भी बड़े टुकड़ों में जोड़ सकते हैं, और इस तरह जब तक हम डोमेन के सभी घटकों का वर्णन कर सकते हैं, जो एक पूरे के लिए आवश्यक हैं। प्रणाली।

यह "एक साथ संयोजन" चरण है जहां हम कुछ कक्षाएं लिख सकते हैं। जब कोई मौजूदा ऑब्जेक्ट नहीं होता है, तो हम कक्षाएं लिखते हैं जो हम चाहते हैं। उदाहरण के लिए, हमारे डोमेन में "फॉस", "बार" कहे जाने वाले फोओस के संग्रह और "बाज़" नामक बार के संग्रह हो सकते हैं। हम देख सकते हैं कि फ़ॉर्स स्ट्रिंग्स के साथ मॉडल करने के लिए पर्याप्त सरल हैं, इसलिए हम ऐसा करते हैं। हम पाते हैं कि सलाखों को कुछ विशेष बाधा का पालन करने के लिए उनकी सामग्री की आवश्यकता होती है जो कि पायथन के किसी भी चीज से मेल नहीं खाती है, इस स्थिति में हम इस बाधा को लागू करने के लिए एक नया वर्ग लिख सकते हैं। शायद बाजों में ऐसी कोई ख़ासियत नहीं है, इसलिए हम सिर्फ एक सूची के साथ उनका प्रतिनिधित्व कर सकते हैं।

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

एक बार हमारे पास अपना डोमेन मॉडल होने के बाद, हम उन टुकड़ों के कुछ विशेष उदाहरण ले सकते हैं और उन्हें उस विशेष प्रणाली के "सिमुलेशन" में व्यवस्थित कर सकते हैं जिसे हम मॉडल करना चाहते हैं (उदाहरण के लिए "मशीन सीखने की प्रणाली ...")।

एक बार जब हमारे पास यह सिमुलेशन होता है, तो हम इसे चला सकते हैं और हे presto, हमारे पास एक काम कर रहे हैं (एक) मशीन लर्निंग सिस्टम के लिए ... (या जो भी हम मॉडलिंग कर रहे थे)।

अब, अपनी विशेष स्थिति में आप "फीचर एक्सट्रैक्टर" घटक के व्यवहार को मॉडल करने का प्रयास कर रहे हैं। सवाल यह है कि क्या कोई अंतर्निहित वस्तुएं हैं जो एक "फीचर एक्सट्रैक्टर" की तरह व्यवहार करती हैं, या आपको इसे सरल चीजों में तोड़ने की आवश्यकता होगी? ऐसा लगता है कि फीचर एक्सट्रैक्टर्स फ़ंक्शन ऑब्जेक्ट्स की तरह बहुत व्यवहार करते हैं, इसलिए मुझे लगता है कि आप अपने मॉडल के रूप में उन का उपयोग करना ठीक होगा।

इस प्रकार की अवधारणाओं के बारे में सीखते समय एक बात का ध्यान रखें कि विभिन्न भाषाएं अलग-अलग अंतर्निहित विशेषताओं और वस्तुओं को प्रदान कर सकती हैं (और, निश्चित रूप से, कुछ भी "वस्तुओं" जैसी शब्दावली का उपयोग नहीं करते हैं!)। इसलिए जो समाधान एक भाषा में समझ में आते हैं वे दूसरे में कम उपयोगी हो सकते हैं (यह एक ही भाषा के विभिन्न संस्करणों पर भी लागू हो सकता है!)।

ऐतिहासिक रूप से, बहुत से ओओपी साहित्य (विशेषकर "डिजाइन पैटर्न") ने जावा पर ध्यान केंद्रित किया है, जो पायथन से काफी अलग है। उदाहरण के लिए, जावा कक्षाएं ऑब्जेक्ट नहीं हैं, जावा के पास बहुत समय तक फ़ंक्शन ऑब्जेक्ट नहीं हैं, जावा में सख्त प्रकार की जांच है (जो इंटरफेस और सबक्लासिंग को प्रोत्साहित करता है) जबकि पायथन डक-टाइपिंग को प्रोत्साहित करता है, जावा में मॉड्यूल ऑब्जेक्ट्स, जावा पूर्णांक / नहीं है तैरता / आदि। ऑब्जेक्ट नहीं हैं, जावा में मेटा-प्रोग्रामिंग / आत्मनिरीक्षण के लिए "प्रतिबिंब" की आवश्यकता होती है, और इसी तरह।

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

आपके मामले में, एक फ़ंक्शन ऑब्जेक्ट एक अच्छा विकल्प की तरह लगता है। यदि आप सोच रहे हैं कि क्यों कुछ "सर्वश्रेष्ठ अभ्यास" दिशानिर्देश किसी संभावित समाधान के रूप में फ़ंक्शन ऑब्जेक्ट का उल्लेख नहीं करते हैं, तो यह केवल इसलिए हो सकता है क्योंकि उन दिशानिर्देशों को जावा के पुराने संस्करणों के लिए लिखा गया था!

— Warbo
स्रोत

0

व्यावहारिक रूप से बोलना, जब मेरे पास "विविध चीज है जो कुछ महत्वपूर्ण करती है और अलग होनी चाहिए", और इसका कोई स्पष्ट घर नहीं है, तो मैं इसे एक Utilitiesअनुभाग में रखता हूं और इसका उपयोग मेरे नामकरण सम्मेलन के रूप में करता हूं। अर्थात। FeatureExtractionUtility।

एक कक्षा में तरीकों की संख्या के बारे में भूल जाओ; एक एकल विधि आज कल पाँच विधियों तक बढ़ने की आवश्यकता हो सकती है। क्या मायने रखता है एक स्पष्ट और सुसंगत संगठनात्मक संरचना, जैसे कि कार्यों के विविध संग्रह के लिए उपयोगिताओं का क्षेत्र।

— Dom
स्रोत

वर्ग जो किसी भी चीज़ का प्रतिनिधित्व नहीं करता है - क्या यह सही है?