हॉलीवुड सिद्धांत (IoC)

इस लेख में, मैं एक डिजाइन सिद्धांत के बारे में बात करने की कोशिश करूंगा जिसे Inversion of Control / IoC भी कहा जाता है, जिसे हॉलीवुड सिद्धांत भी कहा जाता है। मैं दिखाऊंगा कि यह कैसे बारबरा लिस्कोवो (एलएसपी) को प्रतिस्थापित करने के सिद्धांत से संबंधित है, साथ ही साथ पवित्र युद्ध निजी बनाम संरक्षित में योगदान देता है।



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

सभी कोड उदाहरण, हमेशा की तरह, छद्म कोड के साथ लेख में प्रस्तुत किए गए हैं, जिन्हें "नफरत पीएचपी" कहा जाता है।

प्रारंभिक कार्य

इसे तेजी से और अधिक समझने के लिए, हम तुरंत उदाहरण के लिए आगे बढ़ते हैं। बिक्री विभाग से मैं मेट्रिक्स देखना चाहता था: हम मासिक, दैनिक, प्रति घंटा कितना पैसा कमाते हैं।

हम इस समस्या को तीन टीमों की मदद से हल करते हैं जो समय-समय पर चलाए जाते हैं:

• MonthlyReportCommand
• DailyReportCommand
• HourlyRerortCommand

हमें इंटरफेस की आवश्यकता होगी:

interface ReportCommandInterface { public function createReport(): Money; } interface MoneyRepositoryInterface { /** @return Money[] */ public function getMoney(Period $period): array; } interface MetricRepositoryInterface { public function saveMoneyMetric(Period $period, Money $amount, string $metricType); } 

हम रिपोर्ट टीम लिखते हैं (उत्तरार्द्ध को छोड़ दिया जाता है, उन लोगों के लिए एक व्यावहारिक अभ्यास के रूप में जो अच्छी तरह से समझना और अभ्यास करना चाहते हैं, इसे स्वयं लिखें):

 class MonthlyReportCommand implements ReportCommandInterface { //lets assume constructor is already here public function createReport(): Money { $period = new Period(new DateTime('first day of previous month'), new DateTime('last day of previous month')); $moneyRecords = $this->moneyRepository->getMoney($period); $amount = $this->calculateTotals($moneyRecords); $this->metricRepository->saveMoneyMetric($period, $amount, 'monthly income'); } /** @param Money[] $moneyRecords */ private function calculateTotals(array $moneyRecords): Money { //here is calculating sum of money records } } class DailyReportCommand implements ReportCommandInterface { //lets assume constructor is already here public function createReport(): Money { $period = new Period(new DateTime('yesterday'), new DateTime('today')); $moneyRecords = $this->moneyRepository->getMoney($period); $amount = $this->calculateTotals($moneyRecords); $this->metricRepository->saveMoneyMetric($period, $amount, 'daily income'); } /** @param Money[] $moneyRecords */ private function calculateTotals(array $moneyRecords): Money { //here calculates sum of money records } } class HourlyReportCommand ... { //the same as previous two but hourly } 

और हम देखते हैं कि सभी मामलों में कैलकुलेटोटल्स () विधि का कोड बिल्कुल समान होगा। पहली बात जो दिमाग में आती है वह है डुप्लिकेट कोड को एक सामान्य अमूर्त वर्ग में रखना। इस तरह:

 abstract class AbstractReportCommand { protected function calculateTotals(array $moneyRecords): Money { //here calculates sum of money records } } class MonthlyReportCommand extends AbstractReportCommand implements ReportCommandInterface { public function createReport(): Money { //realization is here, calls calculateTotals($moneyRecords) } } class DailyReportCommand extends AbstractReportCommand implements ReportCommandInterface { //the same as previous two but daily } class HourlyReportCommand ... { //the same as previous two but hourly } 

कैलकुलेटोटल्स () विधि हमारी कक्षा के आंतरिक तंत्र का हिस्सा है। हम विवेकपूर्वक इसे बंद कर देते हैं, क्योंकि इसे बाहरी ग्राहकों द्वारा नहीं बुलाया जाना चाहिए - हम इसके लिए इसे डिज़ाइन नहीं कर रहे हैं। हम इस पद्धति को संरक्षित घोषित करते हैं, क्योंकि हमने उसे उत्तराधिकार में बुलाने की योजना बनाई है - यह हमारा लक्ष्य है। जाहिर है, इस तरह के एक अमूर्त वर्ग एक पुस्तकालय की तरह कुछ के समान है - यह सिर्फ कुछ तरीके प्रदान करता है (php विशेषज्ञों के लिए: अर्थात, यह Trait की तरह काम करता है)।

अमूर्त वर्गों का रहस्य

उदाहरण से विराम लेने और अमूर्त वर्गों के उद्देश्य को याद करने का समय है:

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

अमूर्त (lat। Abstractio - व्याकुलता) विवरण और सामान्यीकरण से एक व्याकुलता है। फिलहाल, AbstractReportCommand वर्ग सभी रिपोर्ट के लिए केवल पैसे की गिनती को सामान्य करता है। लेकिन हम हॉलीवुड के सिद्धांत का उपयोग करके अपने अमूर्त को और अधिक कुशल बना सकते हैं, जो इस तरह लगता है:

"हमें फोन मत करो, हम आपको खुद बुलाएंगे"

यह देखने के लिए कि यह कैसे काम करता है, आइए AbstractReportCommand में एक सामान्य रिपोर्टिंग तंत्र डालें:

 abstract class AbstractReportCommand implements ReportCommandInterface { /** @var MoneyRepositoryInterface */ private $moneyRepository; /** @var MetricRepositoryInterface */ private $metricRepository; //lets assume constructor is already here public function createReport(): Money { $period = $this->getPeriod(); $metricType = $this->getMetricType(); $moneyRecords = $this->moneyRepository->getMoney($period); $amount = $this->calculateTotals($moneyRecords); $this->metricRepository->saveMoneyMetric($period, $amount, $metricType); } abstract protected function getPeriod(): Period; abstract protected function getMetricType(): string; private function calculateTotals(array $moneyRecords): Money { //here calculates sum of money records } } class MonthlyReportCommand extends AbstractReportCommand { protected function getPeriod(): Period { return new Period(new DateTime('first day of previous month'), new DateTime('last day of previous month')); } protected function getMetricType(): string { return 'monthly income'; } } class DailyReportCommand extends AbstractReportCommand { protected function getPeriod(): Period { return new Period(new DateTime('yesterday'), new DateTime('today')); } protected function getMetricType(): string { return 'daily income'; } } class HourlyReportCommand ... { //the same as previous two but hourly } 

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

लेकिन क्या वादा किया IoC, LSP, निजी बनाम संरक्षित?

तो इसका उलटा नियंत्रण क्या है? यह नाम कहां से आया है? बहुत सरल: पहले हम अंतिम कार्यान्वयन में सीधे कॉल का क्रम निर्धारित करते हैं, यह नियंत्रित करते हैं कि क्या और कब किया जाएगा। और बाद में, हमने इस तर्क को एक सामान्य अमूर्तता में स्थानांतरित कर दिया। अब अमूर्तता यह नियंत्रित करती है कि क्या और कब कहा जाएगा, और कार्यान्वयन केवल इसी का पालन करते हैं। यानी हमने कंट्रोल को उल्टा कर दिया।

इस व्यवहार को ठीक करने और बारबरा लिस्कोव प्रतिस्थापन सिद्धांत (एलएसपी) के साथ समस्याओं से बचने के लिए, आप विधि घोषणा में अंतिम शामिल करके createReport () विधि को बंद कर सकते हैं। आखिरकार, हर कोई जानता है कि एलएसपी सीधे विरासत से संबंधित है।

 abstract class AbstractReportCommand implements ReportCommandInterface { final public function createReport(): Money { //bla-bla realization } ... } 

तब AbstractReportCommand वर्ग के सभी वंशज कठोर रूप से एक ही तर्क के अधीनस्थ हो जाते हैं जिसे फिर से परिभाषित नहीं किया जा सकता है। लौह अनुशासन, आदेश, उज्ज्वल भविष्य।

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

निष्कर्ष

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

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

उन सभी को धन्यवाद जो ध्यान से शुरू से अंत तक पढ़ते हैं - आप मेरे पसंदीदा पाठक हैं।