9.1 డిపెండెన్సీ ఇన్వర్షన్
గుర్తుంచుకోండి, సర్వర్ అప్లికేషన్‌లో మీరు స్ట్రీమ్‌లను సృష్టించలేరని మేము ఒకసారి చెప్పాము new Thread().start()? కంటైనర్ మాత్రమే థ్రెడ్‌లను సృష్టించాలి. మేము ఇప్పుడు ఈ ఆలోచనను మరింత అభివృద్ధి చేస్తాము.
అన్ని వస్తువులు కూడా కంటైనర్ ద్వారా మాత్రమే సృష్టించబడాలి . వాస్తవానికి, మేము అన్ని వస్తువుల గురించి మాట్లాడటం లేదు, కానీ వ్యాపార వస్తువులు అని పిలవబడే వాటి గురించి. వాటిని తరచుగా డబ్బాలు అని కూడా పిలుస్తారు. ఈ విధానం యొక్క కాళ్ళు SOLID యొక్క ఐదవ సూత్రం నుండి పెరుగుతాయి, దీనికి తరగతులను వదిలించుకోవడం మరియు ఇంటర్‌ఫేస్‌లకు వెళ్లడం అవసరం:
- ఉన్నత-స్థాయి మాడ్యూల్స్ దిగువ-స్థాయి మాడ్యూళ్లపై ఆధారపడకూడదు. ఆ, మరియు ఇతరులు రెండూ నైరూప్యతపై ఆధారపడి ఉండాలి.
- సంగ్రహణలు వివరాలపై ఆధారపడకూడదు. అమలు తప్పనిసరిగా సంగ్రహణపై ఆధారపడి ఉంటుంది.
మాడ్యూల్స్ నిర్దిష్ట అమలులకు సూచనలను కలిగి ఉండకూడదు మరియు వాటి మధ్య అన్ని డిపెండెన్సీలు మరియు పరస్పర చర్యలు కేవలం నైరూప్యత (అంటే ఇంటర్‌ఫేస్‌లు) ఆధారంగా నిర్మించబడాలి. ఈ నియమం యొక్క సారాంశాన్ని ఒక పదబంధంలో వ్రాయవచ్చు: అన్ని డిపెండెన్సీలు ఇంటర్‌ఫేస్‌ల రూపంలో ఉండాలి .
దాని ప్రాథమిక స్వభావం మరియు స్పష్టమైన సరళత ఉన్నప్పటికీ, ఈ నియమం చాలా తరచుగా ఉల్లంఘించబడుతుంది. అవి, ప్రతిసారీ మేము ప్రోగ్రామ్/మాడ్యూల్ కోడ్‌లో కొత్త ఆపరేటర్‌ని ఉపయోగించినప్పుడు మరియు నిర్దిష్ట రకం యొక్క కొత్త వస్తువును సృష్టించినప్పుడు, ఇంటర్‌ఫేస్‌పై ఆధారపడి కాకుండా, అమలుపై ఆధారపడటం ఏర్పడుతుంది.
దీన్ని నివారించలేమని మరియు వస్తువులు ఎక్కడో సృష్టించబడాలని స్పష్టమవుతుంది. కానీ, కనీసం, మీరు దీన్ని చేసే స్థలాల సంఖ్యను మరియు ఏ తరగతులలో స్పష్టంగా పేర్కొనబడిందో కనిష్టీకరించాలి, అలాగే ప్రోగ్రామ్ కోడ్ అంతటా చెల్లాచెదురుగా ఉండకుండా అటువంటి స్థలాలను స్థానికీకరించాలి మరియు వేరుచేయాలి.
ప్రత్యేకమైన వస్తువులు మరియు మాడ్యూల్స్ - ఫ్యాక్టరీలు, సర్వీస్ లొకేటర్లు, IoC కంటైనర్లలో కొత్త వస్తువుల సృష్టిని కేంద్రీకరించడం చాలా మంచి పరిష్కారం.
ఒక రకంగా చెప్పాలంటే, అటువంటి నిర్ణయం సింగిల్ ఛాయిస్ సూత్రాన్ని అనుసరిస్తుంది, ఇది ఇలా చెబుతుంది: "సాఫ్ట్‌వేర్ సిస్టమ్ అనేక ప్రత్యామ్నాయాలకు మద్దతివ్వాలి, వాటి పూర్తి జాబితా సిస్టమ్‌లోని ఒక మాడ్యూల్‌కు మాత్రమే తెలిసి ఉండాలి" .
అందువల్ల, భవిష్యత్తులో కొత్త ఎంపికలను జోడించాల్సిన అవసరం ఉంటే (లేదా కొత్త అమలులు, మేము పరిశీలిస్తున్న కొత్త వస్తువులను సృష్టించే విషయంలో), అప్పుడు ఈ సమాచారాన్ని కలిగి ఉన్న మాడ్యూల్ మరియు అన్ని ఇతర మాడ్యూల్‌లను మాత్రమే నవీకరించడం సరిపోతుంది. ప్రభావితం కాకుండా ఉంటారు మరియు వారి పనిని యధావిధిగా కొనసాగించగలరు.
ఉదాహరణ 1
new ArrayList వంటిది వ్రాయడానికి బదులుగా, List.new()JDK ఒక లీఫ్ యొక్క సరైన అమలును మీకు అందించడానికి అర్ధమే : ArrayList, LinkedList లేదా ConcurrentList కూడా.
ఉదాహరణకు, కంపైలర్ వివిధ థ్రెడ్‌ల నుండి ఆబ్జెక్ట్‌కు కాల్‌లు ఉన్నాయని చూస్తాడు మరియు అక్కడ థ్రెడ్-సురక్షిత అమలును ఉంచుతుంది. లేదా షీట్ మధ్యలో చాలా ఇన్‌సర్ట్‌లు, ఆపై అమలు లింక్డ్‌లిస్ట్ ఆధారంగా ఉంటుంది.
ఉదాహరణ 2
ఇది ఇప్పటికే కొన్ని రకాలతో జరిగింది, ఉదాహరణకు. సేకరణను క్రమబద్ధీకరించడానికి మీరు చివరిసారిగా సార్టింగ్ అల్గారిథమ్‌ను ఎప్పుడు వ్రాసారు? బదులుగా, ఇప్పుడు ప్రతి ఒక్కరూ పద్ధతిని ఉపయోగిస్తున్నారు Collections.sort(), మరియు సేకరణలోని అంశాలు తప్పనిసరిగా పోల్చదగిన ఇంటర్‌ఫేస్‌కు (పోల్చదగినవి) మద్దతివ్వాలి.
sort()మీరు 10 కంటే తక్కువ మూలకాల సేకరణను పద్ధతికి పంపితే, దానిని క్విక్‌సార్ట్ కాకుండా బబుల్ క్రమబద్ధీకరణ (బబుల్ క్రమబద్ధీకరణ)తో క్రమబద్ధీకరించడం చాలా సాధ్యమే .
ఉదాహరణ 3
కంపైలర్ ఇప్పటికే మీరు స్ట్రింగ్‌లను ఎలా కలుస్తారో చూస్తోంది మరియు మీ కోడ్‌ని తో భర్తీ చేస్తుంది StringBuilder.append().
9.2 ఆచరణలో డిపెండెన్సీ విలోమం
ఇప్పుడు అత్యంత ఆసక్తికరమైనది: మనం సిద్ధాంతం మరియు అభ్యాసాన్ని ఎలా కలపవచ్చు అనే దాని గురించి ఆలోచిద్దాం. మాడ్యూల్‌లు వాటి “డిపెండెన్సీలను” ఎలా సరిగ్గా సృష్టించగలవు మరియు స్వీకరించగలవు మరియు డిపెండెన్సీ ఇన్వర్షన్‌ను ఉల్లంఘించకుండా ఎలా ఉంటాయి?
దీన్ని చేయడానికి, మాడ్యూల్ రూపకల్పన చేసేటప్పుడు, మీరు మీ కోసం నిర్ణయించుకోవాలి:
- మాడ్యూల్ ఏమి చేస్తుంది, అది ఏ పని చేస్తుంది;
- అప్పుడు మాడ్యూల్ దాని పర్యావరణం నుండి అవసరం, అంటే, అది ఏ వస్తువులు / మాడ్యూళ్ళతో వ్యవహరించాలి;
- మరియు అతను దానిని ఎలా పొందుతాడు?
డిపెండెన్సీ ఇన్వర్షన్ సూత్రాలకు అనుగుణంగా, మీ మాడ్యూల్ ఏ బాహ్య వస్తువులను ఉపయోగిస్తుందో మరియు వాటికి సూచనలను ఎలా పొందాలో మీరు ఖచ్చితంగా నిర్ణయించుకోవాలి.
మరియు ఇక్కడ క్రింది ఎంపికలు ఉన్నాయి:
- మాడ్యూల్ స్వయంగా వస్తువులను సృష్టిస్తుంది;
- మాడ్యూల్ కంటైనర్ నుండి వస్తువులను తీసుకుంటుంది;
- వస్తువులు ఎక్కడ నుండి వచ్చాయో మాడ్యూల్‌కు తెలియదు.
సమస్య ఏమిటంటే, ఒక వస్తువును సృష్టించడానికి, మీరు ఒక నిర్దిష్ట రకం యొక్క కన్స్ట్రక్టర్‌ను కాల్ చేయాలి మరియు ఫలితంగా, మాడ్యూల్ ఇంటర్‌ఫేస్‌పై కాకుండా నిర్దిష్ట అమలుపై ఆధారపడి ఉంటుంది. కానీ మాడ్యూల్ కోడ్‌లో వస్తువులు స్పష్టంగా సృష్టించబడకూడదనుకుంటే, మేము ఫ్యాక్టరీ పద్ధతి నమూనాను ఉపయోగించవచ్చు .
"బాటమ్ లైన్ ఏమిటంటే, ఒక వస్తువును నేరుగా కొత్త ద్వారా ఇన్‌స్టాంటియేట్ చేయడానికి బదులుగా, మేము ఆబ్జెక్ట్‌లను రూపొందించడానికి క్లయింట్ తరగతికి కొంత ఇంటర్‌ఫేస్‌ను అందిస్తాము. అటువంటి ఇంటర్‌ఫేస్ ఎల్లప్పుడూ సరైన డిజైన్‌తో భర్తీ చేయబడుతుంది కాబట్టి, తక్కువ-స్థాయి మాడ్యూల్‌లను ఉపయోగిస్తున్నప్పుడు మేము కొంత సౌలభ్యాన్ని పొందుతాము. ఉన్నత-స్థాయి మాడ్యూళ్ళలో" .
సంబంధిత వస్తువుల సమూహాలు లేదా కుటుంబాలను సృష్టించాల్సిన అవసరం ఉన్న సందర్భాల్లో, ఫ్యాక్టరీ పద్ధతికి బదులుగా వియుక్త కర్మాగారం ఉపయోగించబడుతుంది .
9.3 సర్వీస్ లొకేటర్‌ని ఉపయోగించడం
మాడ్యూల్ అవసరమైన వస్తువులను ఇప్పటికే కలిగి ఉన్న వారి నుండి తీసుకుంటుంది. సిస్టమ్‌లో కొన్ని వస్తువుల రిపోజిటరీ ఉందని భావించబడుతుంది, దీనిలో మాడ్యూల్స్ తమ వస్తువులను "పెట్టవచ్చు" మరియు రిపోజిటరీ నుండి వస్తువులను "తీసుకోవచ్చు".
ఈ విధానం సర్వీస్ లొకేటర్ నమూనా ద్వారా అమలు చేయబడుతుంది , దీని యొక్క ప్రధాన ఆలోచన ఏమిటంటే, ప్రోగ్రామ్‌లో అవసరమైన అన్ని డిపెండెన్సీలను (సేవలు) ఎలా పొందాలో తెలిసిన వస్తువు ఉంది.
కర్మాగారాల నుండి ప్రధాన వ్యత్యాసం ఏమిటంటే, సర్వీస్ లొకేటర్ వస్తువులను సృష్టించదు, కానీ వాస్తవానికి ఇప్పటికే తక్షణ వస్తువులను కలిగి ఉంది (లేదా వాటిని ఎక్కడ / ఎలా పొందాలో తెలుసు, మరియు అది సృష్టించినట్లయితే, మొదటి కాల్‌లో ఒకసారి మాత్రమే). ప్రతి కాల్ వద్ద ఉన్న ఫ్యాక్టరీ మీరు పూర్తి యాజమాన్యాన్ని పొందే కొత్త వస్తువును సృష్టిస్తుంది మరియు మీరు దానితో మీకు కావలసినది చేయవచ్చు.
ముఖ్యమైనది ! సర్వీస్ లొకేటర్ ఇప్పటికే ఉన్న వస్తువులకు సూచనలను ఉత్పత్తి చేస్తుంది . అందువల్ల, సర్వీస్ లొకేటర్ జారీ చేసిన వస్తువులతో మీరు చాలా జాగ్రత్తగా ఉండాలి, ఎందుకంటే మీరు ఉపయోగించే సమయంలో మరొకరు వాటిని ఉపయోగించవచ్చు.
సర్వీస్ లొకేటర్‌లోని ఆబ్జెక్ట్‌లు నేరుగా కాన్ఫిగరేషన్ ఫైల్ ద్వారా జోడించబడతాయి మరియు ప్రోగ్రామర్‌కు ఏ విధంగానైనా సౌకర్యవంతంగా ఉంటాయి. సర్వీస్ లొకేటర్ అనేది స్టాటిక్ మెథడ్స్, సింగిల్‌టన్ లేదా ఇంటర్‌ఫేస్‌తో కూడిన స్టాటిక్ క్లాస్ కావచ్చు మరియు కన్స్ట్రక్టర్ లేదా మెథడ్ ద్వారా అవసరమైన తరగతులకు పంపబడుతుంది.
సర్వీస్ లొకేటర్‌ను కొన్నిసార్లు వ్యతిరేక నమూనాగా పిలుస్తారు మరియు నిరుత్సాహపరచబడుతుంది (ఎందుకంటే ఇది అవ్యక్త కనెక్షన్‌లను సృష్టిస్తుంది మరియు మంచి డిజైన్ రూపాన్ని మాత్రమే ఇస్తుంది). మీరు మార్క్ సీమాన్ నుండి మరింత చదవవచ్చు:
9.4 డిపెండెన్సీ ఇంజెక్షన్
మాడ్యూల్ "మైనింగ్" డిపెండెన్సీల గురించి అస్సలు పట్టించుకోదు. ఇది పని చేయడానికి ఏమి అవసరమో మాత్రమే నిర్ణయిస్తుంది మరియు అవసరమైన అన్ని డిపెండెన్సీలు బయటి నుండి మరొకరి ద్వారా సరఫరా చేయబడతాయి (పరిచయం చేయబడ్డాయి).
దీన్నే అంటారు - డిపెండెన్సీ ఇంజెక్షన్. సాధారణంగా, అవసరమైన డిపెండెన్సీలు కన్స్ట్రక్టర్ పారామీటర్‌లుగా (కన్స్ట్రక్టర్ ఇంజెక్షన్) లేదా క్లాస్ మెథడ్స్ (సెట్టర్ ఇంజెక్షన్) ద్వారా పాస్ చేయబడతాయి.
ఈ విధానం డిపెండెన్సీలను సృష్టించే ప్రక్రియను విలోమం చేస్తుంది - మాడ్యూల్‌కు బదులుగా, డిపెండెన్సీల సృష్టి బయటి నుండి ఎవరైనా నియంత్రించబడుతుంది. వస్తువుల చురుకైన ఉద్గారిణి నుండి మాడ్యూల్ నిష్క్రియంగా మారుతుంది - ఇది సృష్టించేది అతను కాదు, ఇతరులు అతని కోసం సృష్టిస్తారు.
దిశలో ఈ మార్పును ఇన్వర్షన్ ఆఫ్ కంట్రోల్ లేదా హాలీవుడ్ సూత్రం అని పిలుస్తారు - "మమ్మల్ని పిలవకండి, మేము మీకు కాల్ చేస్తాము."
ఇది అత్యంత సౌకర్యవంతమైన పరిష్కారం, మాడ్యూల్‌లకు గొప్ప స్వయంప్రతిపత్తిని ఇస్తుంది . ఇది మాత్రమే "సింగిల్ రెస్పాన్సిబిలిటీ ప్రిన్సిపల్"ని పూర్తిగా అమలు చేస్తుందని మేము చెప్పగలం - మాడ్యూల్ దాని పనిని బాగా చేయడంపై పూర్తిగా దృష్టి పెట్టాలి మరియు మరేదైనా చింతించకూడదు.
పని కోసం అవసరమైన ప్రతిదానితో మాడ్యూల్‌ను అందించడం అనేది ఒక ప్రత్యేక పని, ఇది తగిన "స్పెషలిస్ట్" ద్వారా నిర్వహించబడుతుంది (సాధారణంగా ఒక నిర్దిష్ట కంటైనర్, IoC కంటైనర్, డిపెండెన్సీలను నిర్వహించడానికి మరియు వాటి అమలుకు బాధ్యత వహిస్తుంది).
వాస్తవానికి, ఇక్కడ ప్రతిదీ జీవితంలో లాగా ఉంటుంది: బాగా వ్యవస్థీకృత సంస్థలో, ప్రోగ్రామర్లు ప్రోగ్రామ్, మరియు డెస్క్‌లు, కంప్యూటర్లు మరియు పని కోసం అవసరమైన ప్రతిదాన్ని కార్యాలయ నిర్వాహకుడు కొనుగోలు చేసి అందిస్తారు. లేదా, మీరు ప్రోగ్రామ్ యొక్క రూపకాన్ని కన్స్ట్రక్టర్‌గా ఉపయోగిస్తే, మాడ్యూల్ వైర్‌ల గురించి ఆలోచించకూడదు, మరొకరు కన్స్ట్రక్టర్‌ను అసెంబ్లింగ్ చేయడంలో పాల్గొంటారు మరియు భాగాలు తాము కాదు.
మాడ్యూల్స్ (డిపెండెన్సీ ఇన్వర్షన్) మధ్య డిపెండెన్సీలను వివరించడానికి ఇంటర్‌ఫేస్‌ల ఉపయోగం + ఈ డిపెండెన్సీల యొక్క సరైన సృష్టి మరియు ఇంజెక్షన్ (ప్రధానంగా డిపెండెన్సీ ఇంజెక్షన్) డీకప్లింగ్ కోసం కీలకమైన సాంకేతికతలు అని చెప్పడం అతిశయోక్తి కాదు .
అవి కోడ్ యొక్క వదులుగా కలపడం, దాని సౌలభ్యం, మార్పులకు నిరోధకత, పునర్వినియోగం మరియు ఇది లేకుండా అన్ని ఇతర సాంకేతికతలకు అంతగా అర్థం లేని పునాదిగా పనిచేస్తాయి. ఇది వదులుగా కలపడం మరియు మంచి నిర్మాణం యొక్క పునాది.
ఇన్వర్షన్ ఆఫ్ కంట్రోల్ సూత్రం (డిపెండెన్సీ ఇంజెక్షన్ మరియు సర్వీస్ లొకేటర్‌తో కలిపి) మార్టిన్ ఫౌలర్ ద్వారా వివరంగా చర్చించబడింది. అతని రెండు వ్యాసాల అనువాదాలు ఉన్నాయి: "ఇన్వర్షన్ ఆఫ్ కంట్రోల్ కంటైనర్లు మరియు డిపెండెన్సీ ఇంజెక్షన్ ప్యాటర్న్" మరియు "ఇన్వర్షన్ ఆఫ్ కంట్రోల్" .