ప్రత్యక్ష డిపెండెన్సీలను మెసేజింగ్‌తో భర్తీ చేస్తోంది
కొన్నిసార్లు మాడ్యూల్‌లో కొన్ని ఈవెంట్‌లు/మార్పులు జరిగినట్లు ఇతరులకు తెలియజేయాలి మరియు ఈ సమాచారం తర్వాత ఏమి జరిగినా పట్టింపు లేదు.
ఈ సందర్భంలో, మాడ్యూల్‌లు “ఒకదానికొకటి తెలుసుకోవలసిన అవసరం లేదు”, అంటే ప్రత్యక్ష లింక్‌లను కలిగి ఉంటుంది మరియు నేరుగా ఇంటరాక్ట్ అవుతుంది, కానీ సందేశాలు (సందేశాలు) లేదా ఈవెంట్‌లు (ఈవెంట్‌లు) మార్పిడి చేయడానికి ఇది సరిపోతుంది.
కొన్నిసార్లు మెసేజింగ్ ద్వారా మాడ్యూల్ కమ్యూనికేషన్ డైరెక్ట్ డిపెండెన్సీ కంటే చాలా బలహీనంగా ఉన్నట్లు అనిపిస్తుంది. నిజానికి, పద్ధతులు పిలవబడనందున, తరగతుల గురించి సమాచారం లేదు. అయితే ఇది భ్రమ తప్ప మరొకటి కాదు.
పద్ధతి పేర్లకు బదులుగా, తర్కం సందేశ రకాలు, వాటి పారామితులు మరియు ప్రసారం చేయబడిన డేటాతో ముడిపడి ఉంటుంది. అటువంటి మాడ్యూల్స్ యొక్క కనెక్టివిటీ స్మెర్ చేయబడింది.
ఇది ఇలా ఉండేది: మేము పద్ధతులను పిలుస్తాము - కనెక్టివిటీ ఉంది, మేము పద్ధతులను పిలవము - కనెక్టివిటీ లేదు. ఇప్పుడు మాడ్యూల్ A దాని సందేశాలలో కొద్దిగా భిన్నమైన డేటాను పంపడం ప్రారంభించిందని ఊహించండి. మరియు అదే సమయంలో, ఈ సందేశాలపై ఆధారపడిన అన్ని మాడ్యూల్స్ సరిగ్గా పని చేయవు.
ఇంతకుముందు, కొత్త వినియోగదారుని జోడించేటప్పుడు, అధికార మాడ్యూల్ USER_ADDED సందేశాన్ని పంపిందని అనుకుందాం మరియు నవీకరణ తర్వాత, నమోదు చేయడానికి ప్రయత్నించినప్పుడు మరియు అదనంగా విజయవంతమైన నమోదును సూచించేటప్పుడు ఈ సందేశాన్ని పంపడం ప్రారంభించింది లేదా పారామితులలో కాదు.
అందువల్ల, సందేశ యంత్రాంగాన్ని చాలా సమర్థవంతంగా అమలు చేయడం చాలా ముఖ్యం. దీని కోసం వివిధ టెంప్లేట్లు ఉన్నాయి.
పరిశీలకుడు. ఇది ఒకటి నుండి అనేక డిపెండెన్సీ విషయంలో ఉపయోగించబడుతుంది, అనేక మాడ్యూల్స్ ఒక రాష్ట్రంపై ఆధారపడి ఉన్నప్పుడు - ప్రధానమైనది. ఇది మెయిలింగ్ మెకానిజంను ఉపయోగిస్తుంది, అంటే ప్రధాన మాడ్యూల్ దాని చందాదారులందరికీ ఒకే సందేశాలను పంపుతుంది మరియు ఈ సమాచారంపై ఆసక్తి ఉన్న మాడ్యూల్‌లు “చందాదారు” ఇంటర్‌ఫేస్‌ను అమలు చేస్తాయి మరియు మెయిలింగ్ జాబితాకు సభ్యత్వాన్ని పొందుతాయి.
ఈ విధానం వినియోగదారు ఇంటర్‌ఫేస్‌తో కూడిన సిస్టమ్‌లలో విస్తృతంగా ఉపయోగించబడుతుంది, అప్లికేషన్ (మోడల్) యొక్క కోర్ స్వతంత్రంగా ఉండటానికి అనుమతిస్తుంది, అయితే దాని అనుబంధిత ఇంటర్‌ఫేస్‌లకు ఏదో మార్పు వచ్చిందని మరియు నవీకరించబడాలి.
ఇక్కడ సందేశ ఆకృతి ఆపరేటింగ్ సిస్టమ్ స్థాయిలో ప్రమాణీకరించబడింది, దీని డెవలపర్లు వెనుకబడిన అనుకూలత మరియు మంచి డాక్యుమెంటేషన్‌ను జాగ్రత్తగా చూసుకోవాలి.
సందేశాల పంపిణీ ద్వారా పరస్పర చర్య యొక్క సంస్థకు అదనపు "బోనస్" ఉంది - "ప్రచురించబడిన" (అంటే పంపబడిన) సందేశాలకు "చందాదారుల" ఐచ్ఛిక ఉనికి. ఇలాంటి చక్కగా రూపొందించబడిన సిస్టమ్ మాడ్యూల్‌లను ఎప్పుడైనా జోడించడానికి/తొలగించడానికి అనుమతిస్తుంది.
మెసేజింగ్ బస్సు
మీరు సందేశాల మార్పిడిని నిర్వహించవచ్చు మరియు దీని కోసం మధ్యవర్తి నమూనాను వేరే విధంగా ఉపయోగించవచ్చు .
మాడ్యూల్స్ మధ్య అనేక నుండి అనేక ఆధారపడటం ఉన్నప్పుడు ఇది ఉపయోగించబడుతుంది. మధ్యవర్తి మాడ్యూళ్ల మధ్య కమ్యూనికేషన్‌లో మధ్యవర్తిగా వ్యవహరిస్తాడు, కమ్యూనికేషన్ సెంటర్‌గా వ్యవహరిస్తాడు మరియు మాడ్యూల్స్ ఒకదానికొకటి స్పష్టంగా సూచించాల్సిన అవసరాన్ని తొలగిస్తాడు.
ఫలితంగా, ఒకదానితో ఒకటి మాడ్యూల్స్ యొక్క పరస్పర చర్య ("అన్నీ అందరితో") మధ్యవర్తి ("అందరితో ఒకటి")తో మాత్రమే మాడ్యూల్స్ యొక్క పరస్పర చర్య ద్వారా భర్తీ చేయబడుతుంది. మధ్యవర్తి బహుళ మాడ్యూళ్ల మధ్య పరస్పర చర్యను సంగ్రహిస్తుంది.
ఇది స్మార్ట్ మధ్యవర్తి అని పిలవబడేది . డెవలపర్లు చాలా తరచుగా వారి క్రచ్‌లను జోడించడం ప్రారంభిస్తారు, ఇది నిర్దిష్ట సందేశాలను స్వీకరించడం ఆన్ / ఆఫ్ చేయడం ద్వారా వ్యక్తిగత మాడ్యూళ్ల ప్రవర్తనను ప్రభావితం చేస్తుంది.
ఒక సాధారణ నిజ జీవిత ఉదాహరణ విమానాశ్రయ ట్రాఫిక్ నియంత్రణ. విమానం నుండి అన్ని సందేశాలు నేరుగా విమానం మధ్య పంపబడకుండా కంట్రోలర్ యొక్క కంట్రోల్ టవర్‌కి వెళ్తాయి. మరియు కంట్రోలర్ ఇప్పటికే ఏ విమానాలు టేకాఫ్ లేదా ల్యాండింగ్ చేయాలనే దాని గురించి నిర్ణయాలు తీసుకుంటుంది మరియు క్రమంగా, విమానాలకు సందేశాలను పంపుతుంది.
ముఖ్యమైనది! మాడ్యూల్స్ ఒకదానికొకటి సాధారణ సందేశాలను మాత్రమే కాకుండా, కమాండ్ వస్తువులను కూడా పంపగలవు. ఇటువంటి పరస్పర చర్య కమాండ్ టెంప్లేట్ ద్వారా వివరించబడింది. ఒక నిర్దిష్ట చర్యను ప్రత్యేక వస్తువుగా చేయమని అభ్యర్థనను సంగ్రహించడం బాటమ్ లైన్.
వాస్తవానికి, ఈ ఆబ్జెక్ట్ ఒకే ఎగ్జిక్యూట్() పద్ధతిని కలిగి ఉంటుంది, ఇది ఈ చర్యను పరామితిగా అమలు చేయడానికి ఇతర మాడ్యూల్‌లకు పంపడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు సాధారణంగా సాధారణ వస్తువులపై చేయగలిగే కమాండ్ ఆబ్జెక్ట్‌తో ఏదైనా ఆపరేషన్‌లను చేస్తుంది.
డిమీటర్ యొక్క చట్టం
లా ఆఫ్ డిమీటర్ అవ్యక్త డిపెండెన్సీల వినియోగాన్ని నిషేధిస్తుంది: "ఆబ్జెక్ట్ A ఆబ్జెక్ట్ Bకి యాక్సెస్ కలిగి ఉంటే మరియు ఆబ్జెక్ట్ Bకి ఆబ్జెక్ట్ Cకి యాక్సెస్ ఉంటే ఆబ్జెక్ట్ A నేరుగా ఆబ్జెక్ట్ C యాక్సెస్ చేయలేకపోతుంది."
దీనర్థం కోడ్‌లోని అన్ని డిపెండెన్సీలు తప్పనిసరిగా “స్పష్టంగా” ఉండాలి - తరగతులు / మాడ్యూల్స్ తమ పనిలో “వాటి డిపెండెన్సీలను” మాత్రమే ఉపయోగించగలవు మరియు వాటి ద్వారా ఇతరులకు ఎక్కకూడదు. ఒక మంచి ఉదాహరణ త్రీ-టైర్ ఆర్కిటెక్చర్. ఇంటర్‌ఫేస్ లేయర్ లాజిక్ లేయర్‌తో పని చేయాలి, కానీ డేటాబేస్ లేయర్‌తో నేరుగా ఇంటరాక్ట్ అవ్వకూడదు.
క్లుప్తంగా, ఈ సూత్రం ఈ విధంగా కూడా రూపొందించబడింది: "తక్షణ స్నేహితులతో మాత్రమే సంభాషించండి మరియు స్నేహితుల స్నేహితులతో కాదు." ఇది కోడ్ యొక్క తక్కువ పొందికను, అలాగే దాని రూపకల్పన యొక్క ఎక్కువ దృశ్యమానత మరియు పారదర్శకతను సాధిస్తుంది.
డిమీటర్ యొక్క చట్టం ఇప్పటికే పేర్కొన్న “కనీస జ్ఞానం యొక్క సూత్రాన్ని” అమలు చేస్తుంది, ఇది వదులుగా కలపడానికి ఆధారం మరియు ఒక వస్తువు / మాడ్యూల్ ఇతర వస్తువులు / మాడ్యూల్స్ యొక్క నిర్మాణం మరియు లక్షణాల గురించి వీలైనంత తక్కువ వివరాలను తెలుసుకోవాలి మరియు దాని స్వంత భాగాలతో సహా సాధారణంగా ఏదైనా .
జీవితం నుండి ఒక సారూప్యత: మీరు కుక్క పరుగెత్తాలని కోరుకుంటే, దాని పాదాలను ఆదేశించడం తెలివితక్కువది, కుక్కకు ఆదేశం ఇవ్వడం మంచిది, మరియు ఆమె తన పాదాలతో స్వయంగా వ్యవహరిస్తుంది.
వారసత్వానికి బదులుగా కూర్పు
ఇది చాలా పెద్ద మరియు ఆసక్తికరమైన అంశం మరియు ఇది కనీసం ప్రత్యేక ఉపన్యాసానికి అర్హమైనది. ఏకాభిప్రాయం వచ్చే వరకు ఇంటర్నెట్‌లో ఈ అంశంపై చాలా కాపీలు విభజించబడ్డాయి - మేము వారసత్వాన్ని కనిష్టంగా, కూర్పుకు - గరిష్టంగా ఉపయోగిస్తాము.
పాయింట్ ఏమిటంటే వారసత్వం వాస్తవానికి తరగతుల మధ్య బలమైన సంబంధాన్ని అందిస్తుంది, కాబట్టి దీనిని నివారించాలి. ఈ అంశం హెర్బ్ సుటర్ యొక్క వ్యాసం " వారసత్వం కంటే కూర్పుకు ప్రాధాన్యత ఇవ్వండి "లో బాగా కవర్ చేయబడింది.
మీరు డిజైన్ నమూనాలను నేర్చుకోవడం ప్రారంభించినప్పుడు, మీరు ఒక వస్తువు యొక్క సృష్టిని లేదా దాని అంతర్గత నిర్మాణాన్ని నియంత్రించే మొత్తం నమూనాలను చూస్తారు. మార్గం ద్వారా, గేమ్‌ల నుండి వచ్చిన డెలిగేట్ / డెలిగేట్ ప్యాటర్న్ మరియు కాంపోనెంట్ ప్యాటర్న్‌పై శ్రద్ధ పెట్టమని నేను ఈ సందర్భంలో సలహా ఇవ్వగలను .
మేము కొంచెం తర్వాత నమూనాల గురించి మరింత మాట్లాడుతాము.