"హలో, అమిగో! నేను మీకు OOP యొక్క మరొక ప్రయోజనం గురించి చెప్పాలనుకుంటున్నాను. మీరు చూడండి, కార్యక్రమాలు భవనాల కంటే జంతువుల లాంటివి. అవి నిర్మించబడలేదు, అవి పెరిగాయి. అభివృద్ధి అంటే స్థిరమైన మార్పులు. నిర్మాణంలో, మీరు చేయవచ్చు ఒక మంచి ప్రణాళికను కలిగి ఉండండి మరియు దానిని T కి అనుసరించండి. కానీ సాఫ్ట్‌వేర్ అభివృద్ధిలో, అది అలా కాదు."
చాలా తరచుగా, మీరు ఉద్దేశించిన విధంగా మీరు ఏదైనా చేయలేరు మరియు మీరు మీ ప్రోగ్రామ్‌ను చాలా రీవర్క్ చేయాలి. మరియు మరింత తరచుగా, కస్టమర్ యొక్క అవసరాలు మారుతాయి.
"అయితే కస్టమర్ నిజంగా వివరణాత్మక వివరణను అందించినట్లయితే?"
"కాలక్రమేణా ఏమి జరుగుతుందో పరిశీలించండి. ఒక ఉత్పత్తి విజయవంతమైతే, కస్టమర్ కొత్త వెర్షన్‌ను విడుదల చేయాలనుకుంటున్నారు, ఆపై మరొకటి మరియు మరొకటి విడుదల చేయాలనుకుంటున్నారు. మరియు, వాస్తవానికి, మీరు కొన్ని « చిన్న మార్పులు » చేయవలసి ఉంటుంది ఇప్పటికే ఉన్న ఉత్పత్తి. కాబట్టి సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ అనేది చాలా మార్పుల శ్రేణి. కేడెన్స్ మాత్రమే భిన్నంగా ఉంటుంది. కొత్త వెర్షన్ ప్రతి వారం, నెలకు ఒకసారి లేదా ప్రతి ఆరు నెలలకు ఒకసారి విడుదల చేయబడవచ్చు."
"కాబట్టి వీటన్నింటి నుండి మనం ఏమి తేల్చాలి?"
"ఉత్పత్తి యొక్క అంతర్గత నిర్మాణం తప్పనిసరిగా ప్రధానమైన (మరియు చిన్న) మార్పులను కనీస రీవర్కింగ్‌తో చేయడానికి అనుమతించే విధంగా నిర్వహించబడాలి."
"మీరు అది ఎలా చేశారు?"
"ఒక ప్రోగ్రామ్ ఒకదానితో ఒకటి పరస్పర చర్య చేసే వస్తువులను ఎలా కలిగి ఉంటుంది అనే దాని గురించి మేము ఇప్పటికే మాట్లాడాము. బోర్డ్‌లోని మా ప్రోగ్రామ్‌లోని అన్ని వస్తువులను సూచించడానికి మందపాటి చుక్కలను ఉపయోగిస్తాము. మేము ప్రతి వస్తువు (డాట్) నుండి అన్ని వస్తువులకు బాణాలను గీస్తాము. (చుక్కలు) దానితో సంకర్షణ చెందుతుంది."
ఇప్పుడు వస్తువులను (చుక్కలు) సమూహాలుగా కలుపుదాం. చుక్కలు ఇతర చుక్కల కంటే ఒకదానికొకటి చాలా ఎక్కువగా అనుసంధానించబడి ఉంటే అదే సమూహానికి చెందినవి. చుక్క యొక్క చాలా బాణాలు దాని సమూహంలోని చుక్కలను సూచిస్తే, మేము వస్తువులను సరిగ్గా సమూహపరుస్తాము. ఒకే సమూహంలోని చుక్కలు గట్టిగా జతచేయబడి ఉంటాయి, వివిధ సమూహాలలో చుక్కలు వదులుగా జతచేయబడతాయి.
దీనిని « వదులుగా కలపడం యొక్క సూత్రం » అని పిలుస్తారు . ప్రోగ్రామ్ అనేక భాగాలుగా విభజించబడింది, తరచుగా పొరలుగా ఉంటుంది, దీని తర్కం వారి అంతర్గత నిర్మాణంతో బలంగా ముడిపడి ఉంటుంది మరియు ఇతర పొరలు/భాగాలతో బలహీనంగా ముడిపడి ఉంటుంది. పొరల మధ్య పరస్పర చర్య సాధారణంగా చాలా కంపార్ట్మెంటలైజ్ చేయబడుతుంది. ఒక పొర దాని తరగతుల యొక్క చిన్న ఉపసమితిని మాత్రమే ఉపయోగించి మరొక పొరను కాల్ చేయగలదు.
"అదే 'కార్మిక విభజన' సూత్రం, కానీ పెద్ద స్థాయిలో?"
"ఖచ్చితంగా. ఇది ఒక విభాగాన్ని పునర్వ్యవస్థీకరించడానికి, దానిని మరింత సమర్థవంతంగా చేయడానికి మరియు మరింత మంది వ్యక్తులను నియమించుకోవడానికి అనుమతిస్తుంది, మరియు మేము ఇంటర్‌డిపార్ట్‌మెంటల్ ప్రోటోకాల్‌లను మార్చకపోతే, మా మార్పులన్నీ స్థానికంగా ఉంటాయి. ఎవరూ మళ్లీ శిక్షణ పొందాల్సిన అవసరం లేదు. మేము చేయము' డిపార్ట్‌మెంటల్ ఇంటరాక్షన్‌కి సంబంధించిన మెకానిజమ్‌లను బాగా ఎంచుకుంటే ప్రతి డిపార్ట్‌మెంట్ తన అంతర్గత వ్యవహారాలను ఈ విధంగా ఆప్టిమైజ్ చేయగలదు."
"వారు బాగా ఎంపిక చేయబడితే. మరియు వారు బాగా ఎంపిక చేయబడకపోతే?"
'అప్పుడు మార్పులు చేయడం కోసం మీరు త్వరగా " విగ్ల్ రూమ్ " అయిపోతారు మరియు మొత్తం సిస్టమ్‌ను మళ్లీ పని చేయాల్సి ఉంటుంది. అది ఎప్పటికప్పుడు జరుగుతూనే ఉంటుంది. మేము భవిష్యత్తును అంచనా వేయలేము, కానీ మేము ప్రోగ్రామ్‌ను తిరిగి వ్రాయవలసిన సంఖ్యను తగ్గించగలము."
"సరే. ప్రోగ్రామ్‌ని అలా విభజించడం వల్ల కలిగే లాభాన్ని నేను చూస్తున్నాను, అయితే OOP చిత్రంలోకి ఎలా వస్తుంది?"
"మేము డిపార్ట్‌మెంట్‌లను ఎలా రూపొందించాలో మరియు అవి ఎలా సంకర్షణ చెందాలో ఎంచుకున్నప్పుడు, మేము ' అబ్‌స్ట్రాక్షన్ సూత్రాన్ని ' వర్తింపజేస్తాము. ప్రోగ్రామింగ్‌లో, ప్రోగ్రామ్‌ను విభజించడానికి మరియు భాగాలు ఎలా సంకర్షణ చెందాలి అనే ఉత్తమ మార్గాన్ని నిర్ణయించడానికి సంగ్రహణ ఉపయోగించబడుతుంది. ఈ సూత్రం మేము ప్రోగ్రామ్‌ను వ్యక్తిగత తరగతులుగా విభజించే వరకు రాజ్యాంగ భాగాలకు కూడా పదేపదే వర్తించబడుతుంది."
"మరియు ఈ భాగాల అంతర్గత నిర్మాణాన్ని దాచడం మరియు అవి ఇతర భాగాలతో ఎలా సంకర్షణ చెందుతాయో ఖచ్చితంగా పరిమితం చేయడం - అది ఎన్‌క్యాప్సులేషన్ , సరియైనదా?"
"సరిగ్గా. ఎన్‌క్యాప్సులేషన్ మరియు సంగ్రహణ OOP యొక్క మూలస్తంభాలు. ఒక మంచి ప్రోగ్రామ్ తప్పనిసరిగా ఈ రెండు సూత్రాలకు కట్టుబడి ఉండాలి. తర్వాత మేము ఇతర సూత్రాలను పరిశీలించి వాటి ప్రయోజనాలను అర్థం చేసుకుంటాము."
"మంచి విషయం. నేను వేచి ఉండలేను!"
GO TO FULL VERSION