क्या अमूर्तता के आधार पर कोई महत्वपूर्ण नुकसान हैं?


9

मैं इस विकी को स्थिर सार सिद्धांत (एसएपी) पर पढ़ रहा था ।

एसएपी बताता है कि जितना अधिक स्थिर पैकेज उतना ही अधिक सार होना चाहिए। इसका तात्पर्य यह है कि यदि कोई पैकेज कम स्थिर है (परिवर्तन की संभावना है) तो यह अधिक ठोस होना चाहिए। मैं वास्तव में नहीं समझ पा रहा हूं कि ऐसा क्यों होना चाहिए। निश्चित रूप से स्थिरता की परवाह किए बिना सभी मामलों में हमें अमूर्तता पर निर्भर होना चाहिए और ठोस कार्यान्वयन को छिपाना चाहिए?


एक घटक का उपयोग करने का प्रयास करें जो आप सहज हैं, जो इसके द्वारा प्रदान किए गए अमूर्तनों का उपयोग करके, लेकिन एक बार में एक स्तर से कम में पूरे विस्तार से कर रहे हैं कि आप इसे इस्तेमाल नहीं कर रहे हैं। यह आपको अमूर्तता के फायदे और नुकसान का एक बहुत अच्छा प्रभाव देगा।
किलिआन फोथ

2
क्या आपने लिंक किए गए लेख और / या उस पुस्तक को पढ़ा है जिस पर लेख आधारित है?
जोर्ग डब्ल्यू मित्तग

1
+1 अच्छा सवाल, खासकर जब से मुझे नहीं लगता कि स्थिरता और अमूर्त के बीच संबंध तुरंत सहज है। इस लेख का पेज 11 मदद करता है, अमूर्त मामले का इसका उदाहरण समझ में आता है, लेकिन शायद कोई ठोस मामले का स्पष्ट उदाहरण लिख सकता है। रिक्वेस्ट ऑफ होल्ड।
माइक

इन एब्स्ट्रैक्ट के लिए आप किस प्रॉब्लम डोमेन से काम कर रहे हैं? जैसा कि C2 पर उल्लेख किया गया है: "वास्तविक दुनिया के डोमेन में मॉडलिंग - ग्राहकों, कर्मचारियों, चालान, बिल-ऑफ-मटिरियल, उत्पाद, SKU, पेचेक, इत्यादि की दुनिया में - स्थिर अमूर्त को ढूंढना मुश्किल हो सकता है। कम्प्यूटेशनल डोमेन - ढेर, कतारों, कार्यों, पेड़ों, प्रक्रियाओं, धागे, चित्रमय विगेट्स, रिपोर्ट, रूप आदि की दुनिया - स्थिर होने की अधिक संभावना है। ” और "कुछ डोमेन में, स्थिर अमूर्त द्वारा आना मुश्किल है।" यह जानने के बिना कि आप SAP के साथ किस समस्या को हल करने की कोशिश कर रहे हैं, इसकी मेहनत आपको एक अच्छा जवाब दे सकती है।

@ JörgWMittag और माइक - हाँ, मैंने लेख पढ़ा। मुझे सिर्फ यह लगता है कि इस बात की कमी है कि "अस्थिर पैकेज ठोस क्यों होने चाहिए"। उक्त लेख के पृष्ठ १३ पर वह एक ग्राफ दिखाता है लेकिन वास्तव में बहुत विस्तार से बताने के लिए नहीं बताता है कि (१ ९९) ग्राफ से क्यों बचा जाना चाहिए? क्या विचार यह है कि मूल रूप से अस्थिर होने का अर्थ है कम निर्भरता और वहाँ अमूर्तता का उपयोग करने की आवश्यकता नहीं है? यदि ऐसा है ... तो क्या एब्स्ट्रैक्शन वैसे भी उपयोग करने के लिए यह अच्छा अभ्यास नहीं है, बस आवश्यकता परिवर्तन के साथ स्थिरता में परिवर्तन होता है ..
स्टीवचैलेंडर

जवाबों:


7

एक API के रूप में अपने पैकेज के बारे में सोचो, कागज से उदाहरण लेते हैं, के लिए परिभाषाएँ लेने Readerके साथ string Reader.Read()और Writerसाथ void Writer.Write(string)अपने सार एपीआई के रूप में।

फिर आप Copyएक विधि Copier.Copy(Reader, Writer)और कार्यान्वयन के साथ एक वर्ग बना सकते हैं Writer.Write(Reader.Read())और शायद कुछ पवित्रता की जाँच करें।

अब, आप ठोस कार्यान्वयन करते हैं, उदाहरण FileReaderके लिए FileWriter, KeyboardReaderऔर DownloadThingsFromTheInternetReader

यदि आप अपना कार्यान्वयन बदलना चाहते हैं तो क्या होगा FileReader? कोई बात नहीं, बस क्लास बदलो और recompile।

यदि आप अपने अमूर्त की परिभाषा को बदलना चाहते हैं तो क्या होगा Reader? ओह, आप सिर्फ इतना है कि नहीं बदल सकते, लेकिन आप यह भी बदलने के लिए होगा Copier, FileReader, KeyboardReaderऔर DownloadThingsFromTheInternetReader

यह स्थिर संचलन सिद्धांत के पीछे का तर्क है: अपने निष्कर्षों को अमूर्त की तुलना में कम स्थिर बनाएं।


1
मैं आपकी हर बात से सहमत हूं, लेकिन मेरा मानना ​​है कि लेखकों की स्थिरता और आपकी परिभाषा अलग है। आप स्थिरता को बदलने की आवश्यकता मानते हैं, लेखक कहता है "स्थिरता इस बात की माप नहीं है कि मॉड्यूल में क्या बदलाव होगा, बल्कि यह एक मॉड्यूल को बदलने में कठिनाई का एक उपाय है।" तो मेरा सवाल यह है कि यह उन पैकेजों के लिए क्यों फायदेमंद है जो आसानी से बदल दिए जाते हैं क्योंकि वे अमूर्त के बजाय अधिक ठोस होते हैं?
15

1
@SteveCallender यह सूक्ष्म अंतर है: "स्थिरता" के लेखक की परिभाषा है जिसे ज्यादातर लोग "स्थिरता की आवश्यकता" कहते हैं, और अधिक मॉड्यूल एक मॉड्यूल पर निर्भर करते हैं, अधिक "स्थिर" एक मॉड्यूल की आवश्यकता होती है।
रेसड्यूमन

6

YAGNI की वजह से ।

यदि आपके पास वर्तमान में केवल एक चीज का कार्यान्वयन है , तो एक अतिरिक्त और बेकार परत से परेशान क्यों हो? यह केवल अनावश्यक जटिलता को जन्म देगा। इससे भी बदतर, कभी-कभी आप एक अमूर्त सोच प्रदान करते हैं जिस दिन एक दूसरा कार्यान्वयन आएगा ... और यह दिन कभी नहीं होता है। किस काम की बर्बादी!

मुझे यह भी लगता है कि खुद से पूछने के लिए असली सवाल "क्या मुझे गर्भपात पर निर्भर रहने की आवश्यकता है?" बल्कि "क्या मुझे प्रतिरूपकता की आवश्यकता है?"। और प्रतिरूपकता की हमेशा आवश्यकता नहीं होती है, नीचे देखें।

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

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


1
मैं YAGNI से सहमत हूं, लेकिन मुझे आपके उदाहरण पर आश्चर्य है। क्या आप विभिन्न उपकरणों में कोई कोड नहीं दोहरा रहे हैं ? मुझे यह विश्वास करना मुश्किल है कि एक ही कंपनी के उपकरणों में कुछ सामान्य कोड नहीं है। इसके अलावा, जब आप अपने फर्मवेयर में बग को ठीक नहीं करते हैं तो ग्राहक कैसे पसंद करते हैं? क्या आप कह रहे हैं कि कभी कीड़े, कभी नहीं हैं ? यदि आपके पास एक ही कोड है जो 4 अलग-अलग कार्यान्वयन में छोटी गाड़ी है, तो आपको बग को 4 बार ठीक करना होगा यदि यह एक सामान्य मॉड्यूल में नहीं है।
फ्यूहरमैनटर

1
@Fuhrmanator आम कोड सार से अलग है। कॉमन कोड का मतलब सिर्फ एक सहायक विधि या पुस्तकालय हो सकता है - किसी भी सार की आवश्यकता नहीं है।
ईलोन

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

@ मेरी टिप्पणी के बारे में प्रतिरूपकता हमेशा (अमूर्त नहीं) की जरूरत नहीं है।
फ्यूहरमैनटर

@ स्पॉट किया गया पैच नहीं होने के बारे में कोई समस्या नहीं है। यह सिर्फ एक बहुत ही विशिष्ट उदाहरण है और अधिकांश सॉफ्टवेयर का विशिष्ट नहीं है।
19

6

मैं तुम्हें शायद शब्द कारण असमंजस में हैं लगता है स्थिर रॉबर्ट मार्टिन द्वारा चुना। यहां मुझे लगता है कि भ्रम शुरू होता है:

इसका तात्पर्य यह है कि यदि कोई पैकेज कम स्थिर है (परिवर्तन की अधिक संभावना है) तो यह अधिक ठोस होना चाहिए।

यदि आप मूल लेख के माध्यम से पढ़ते हैं , तो आप देखेंगे (जोर मेरा):

शब्द स्थिरता की क्लासिक परिभाषा है: "आसानी से स्थानांतरित नहीं किया गया।" इस परिभाषा का उपयोग हम इस लेख में करेंगे। यही है, स्थिरता संभावना की माप नहीं है कि एक मॉड्यूल बदल जाएगा; बल्कि यह एक मॉड्यूल को बदलने में कठिनाई का एक उपाय है

स्पष्ट रूप से, मॉड्यूल जो बदलने में अधिक कठिन हैं, कम अस्थिर होने जा रहे हैं। मॉड्यूल को बदलना जितना कठिन है, उतना ही स्थिर होगा, उतना ही कम अस्थिर होगा।

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

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

इसलिए, "ज़िम्मेदार" की भावना का पालन करते हुए मैं बदलाव के लिए वैकल्पिक अर्थों के साथ आया (या नहीं बदलना चाहिए ):

  • अनिवार्य - अर्थ है कि अन्य वर्ग इस वर्ग पर निर्भर करते हैं इसलिए इसे बदलना नहीं चाहिए
  • निहारना - ibid।
  • विवश - इस वर्ग के दायित्व बदलने में इसकी सुविधा को सीमित करते हैं।

इसलिए, इन परिभाषाओं को बयान में शामिल करें

जितना अधिक स्थिर पैकेज उतना ही अधिक सारगर्भित होना चाहिए

  • अधिक बाध्य एक पैकेज अधिक सार यह होना चाहिए
  • अधिक कृतज्ञ एक पैकेज अधिक सार यह होना चाहिए
  • अधिक पैकेज एक पैकेज जितना अधिक सार होना चाहिए उतना ही विवश है

आइए स्थिर शब्द सिद्धांत (SAP) का हवाला देते हुए, भ्रमित शब्दों को स्थिर / अस्थिर करने पर जोर दें:

ऐसे पैकेज जो अधिकतम रूप से स्थिर होते हैं, उन्हें अधिकतम सार होना चाहिए। अस्थिर पैकेज ठोस होना चाहिए। एक पैकेज की अमूर्तता इसकी स्थिरता के अनुपात में होनी चाहिए ।

इन भ्रामक शब्दों के बिना इसे स्पष्ट करना:

पैकेज जो कि सिस्टम के अन्य भागों में अधिकतम रूप से निहारना है, अधिकतम रूप से सार होना चाहिए। बिना कठिनाई के बदल सकने वाले पैकेज ठोस होने चाहिए। एक पैकेज की अमूर्तता को संशोधित करना कितना मुश्किल होगा, इसके अनुपात में होना चाहिए ।

टी एल; डॉ

आपके प्रश्न का शीर्षक पूछता है:

क्या अमूर्तता के आधार पर कोई महत्वपूर्ण नुकसान हैं?

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


0

इसका तात्पर्य यह है कि यदि कोई पैकेज कम स्थिर है (परिवर्तन की संभावना है) तो यह अधिक ठोस होना चाहिए। मुझे वास्तव में समझ में नहीं आता है कि ऐसा क्यों होना चाहिए।

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

इसलिए, यदि आपका पैकेज अक्सर बदलने वाला है, तो इसे बेहतर रूप से कंसीलर देना चाहिए, न कि एब्स्ट्रैक्ट। नहीं तो ... आखिर कौन इसका इस्तेमाल करेगा? ;)


0

मार्टिन स्थिरता मीट्रिक को ध्यान में रखें और "स्थिरता" से उसका क्या अर्थ है:

Instability = Ce / (Ca+Ce)

या:

Instability = Outgoing / (Incoming+Outgoing)

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

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

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

क्या अमूर्तता के आधार पर कोई महत्वपूर्ण नुकसान हैं?

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.