కోడింగ్ నియమాలు: సిస్టమ్‌ను సృష్టించడం నుండి వస్తువులతో పని చేయడం వరకు

మంచి రోజు, అందరూ! ఈ రోజు మేము మంచి కోడ్ రాయడం గురించి మీతో మాట్లాడాలనుకుంటున్నాము. వాస్తవానికి, ప్రతి ఒక్కరూ క్లీన్ కోడ్ వంటి పుస్తకాలను వెంటనే నమలాలని కోరుకోరు, ఎందుకంటే అవి విస్తారమైన మొత్తంలో సమాచారాన్ని కలిగి ఉంటాయి కాని మొదట్లో చాలా స్పష్టంగా లేవు. మరియు మీరు చదవడం పూర్తి చేసే సమయానికి, మీరు కోడ్ చేయాలనే మీ కోరికను పూర్తిగా నాశనం చేయవచ్చు. వాటన్నింటిని పరిశీలిస్తే, ఈ రోజు నేను మీకు మెరుగైన కోడ్ రాయడం కోసం ఒక చిన్న గైడ్ (చిన్న సిఫార్సుల సెట్)ని అందించాలనుకుంటున్నాను. ఈ వ్యాసంలో, సిస్టమ్‌ను సృష్టించడం మరియు ఇంటర్‌ఫేస్‌లు, తరగతులు మరియు వస్తువులతో పనిచేయడానికి సంబంధించిన ప్రాథమిక నియమాలు మరియు భావనలను చూద్దాం. ఈ కథనాన్ని చదవడానికి ఎక్కువ సమయం పట్టదు మరియు మీకు విసుగు కలిగించదని నేను ఆశిస్తున్నాను. నేను పై నుండి క్రిందికి, అంటే అప్లికేషన్ యొక్క సాధారణ నిర్మాణం నుండి దాని ఇరుకైన వివరాల వరకు పని చేస్తాను.

వ్యవస్థలు

కిందివి సిస్టమ్ యొక్క సాధారణంగా కావాల్సిన లక్షణాలు:

• కనిష్ట సంక్లిష్టత. మితిమీరిన సంక్లిష్టమైన ప్రాజెక్టులకు దూరంగా ఉండాలి. అతి ముఖ్యమైన విషయం ఏమిటంటే సరళత మరియు స్పష్టత (సరళమైనది = మంచిది).
• నిర్వహణ సౌలభ్యం. అనువర్తనాన్ని సృష్టించేటప్పుడు, దానిని నిర్వహించాల్సిన అవసరం ఉందని మీరు గుర్తుంచుకోవాలి (దాని నిర్వహణకు మీరు వ్యక్తిగతంగా బాధ్యత వహించనప్పటికీ). అంటే కోడ్ స్పష్టంగా మరియు స్పష్టంగా ఉండాలి.
• వదులుగా కలపడం. దీనర్థం మేము ప్రోగ్రామ్‌లోని వివిధ భాగాల మధ్య డిపెండెన్సీల సంఖ్యను తగ్గిస్తాము (OOP సూత్రాలతో మా సమ్మతిని పెంచడం).
• పునర్వినియోగం. మేము మా సిస్టమ్‌ని ఇతర అప్లికేషన్‌లలో కాంపోనెంట్‌లను తిరిగి ఉపయోగించగల సామర్థ్యంతో డిజైన్ చేస్తాము.
• పోర్టబిలిటీ. వ్యవస్థను మరొక వాతావరణానికి అనుగుణంగా మార్చడం సులభం.
• ఏకరీతి శైలి. మేము మా సిస్టమ్‌ని దాని వివిధ భాగాలలో ఏకరీతి శైలిని ఉపయోగించి డిజైన్ చేస్తాము.
• విస్తరణ (స్కేలబిలిటీ). మేము సిస్టమ్‌ను దాని ప్రాథమిక నిర్మాణాన్ని ఉల్లంఘించకుండా మెరుగుపరచగలము (ఒక భాగాన్ని జోడించడం లేదా మార్చడం మిగతా వాటిపై ప్రభావం చూపకూడదు).

మార్పులు లేదా కొత్త కార్యాచరణ అవసరం లేని అప్లికేషన్‌ను రూపొందించడం ఆచరణాత్మకంగా అసాధ్యం. మన మెదడుకు తగినట్లుగా ఉండేందుకు మేము నిరంతరం కొత్త భాగాలను జోడించాల్సి ఉంటుంది. ఇక్కడే స్కేలబిలిటీ అమలులోకి వస్తుంది. స్కేలబిలిటీ అనేది తప్పనిసరిగా అప్లికేషన్‌ను విస్తరించడం, కొత్త కార్యాచరణను జోడించడం మరియు మరిన్ని వనరులతో (లేదా, ఇతర మాటలలో, ఎక్కువ లోడ్‌తో) పని చేయడం. మరో మాటలో చెప్పాలంటే, కొత్త లాజిక్‌ను జోడించడాన్ని సులభతరం చేయడానికి, మాడ్యులారిటీని పెంచడం ద్వారా సిస్టమ్ యొక్క కప్లింగ్‌ను తగ్గించడం వంటి కొన్ని నియమాలకు మేము కట్టుబడి ఉంటాము.

చిత్ర మూలం

వ్యవస్థ రూపకల్పన యొక్క దశలు

1. సాఫ్ట్‌వేర్ సిస్టమ్. మొత్తం అప్లికేషన్‌ను రూపొందించండి.
2. ఉపవ్యవస్థలు/ప్యాకేజీలుగా విభజన. తార్కికంగా విభిన్న భాగాలను నిర్వచించండి మరియు వాటి మధ్య పరస్పర చర్య కోసం నియమాలను నిర్వచించండి.
3. ఉపవ్యవస్థలను తరగతులుగా విభజించడం. సిస్టమ్ యొక్క భాగాలను నిర్దిష్ట తరగతులు మరియు ఇంటర్‌ఫేస్‌లుగా విభజించి, వాటి మధ్య పరస్పర చర్యను నిర్వచించండి.
4. పద్ధతుల్లో తరగతుల విభజన. ఒక తరగతికి కేటాయించబడిన బాధ్యత ఆధారంగా దానికి అవసరమైన పద్ధతులకు పూర్తి నిర్వచనాన్ని సృష్టించండి.
5. పద్ధతి రూపకల్పన. వ్యక్తిగత పద్ధతుల యొక్క కార్యాచరణ యొక్క వివరణాత్మక నిర్వచనాన్ని సృష్టించండి.

సాధారణంగా సాధారణ డెవలపర్లు ఈ డిజైన్‌ను నిర్వహిస్తారు, అయితే అప్లికేషన్ యొక్క ఆర్కిటెక్ట్ పైన వివరించిన పాయింట్లను నిర్వహిస్తారు.

సిస్టమ్ డిజైన్ యొక్క సాధారణ సూత్రాలు మరియు భావనలు

సోమరితనం ప్రారంభించడం. ఈ ప్రోగ్రామింగ్ ఇడియమ్‌లో, ఆబ్జెక్ట్‌ను వాస్తవంగా ఉపయోగించే వరకు అప్లికేషన్ సృష్టించే సమయాన్ని వృథా చేయదు. ఇది ప్రారంభ ప్రక్రియను వేగవంతం చేస్తుంది మరియు చెత్త కలెక్టర్పై లోడ్ను తగ్గిస్తుంది. మీరు దీన్ని చాలా దూరం తీసుకోకూడదు, ఎందుకంటే అది మాడ్యులారిటీ సూత్రాన్ని ఉల్లంఘించవచ్చు. నిర్మాణానికి సంబంధించిన అన్ని సందర్భాలను కొన్ని నిర్దిష్ట భాగానికి తరలించడం విలువైనదే కావచ్చు, ఉదాహరణకు, ప్రధాన పద్ధతి లేదా ఫ్యాక్టరీ తరగతికి. మంచి కోడ్ యొక్క ఒక లక్షణం పునరావృతమయ్యే, బాయిలర్‌ప్లేట్ కోడ్ లేకపోవడం. నియమం ప్రకారం, అటువంటి కోడ్ ప్రత్యేక తరగతిలో ఉంచబడుతుంది, తద్వారా ఇది అవసరమైనప్పుడు పిలవబడుతుంది.

AOP

నేను కారక-ఆధారిత ప్రోగ్రామింగ్‌ను కూడా గమనించాలనుకుంటున్నాను. ఈ ప్రోగ్రామింగ్ నమూనా పారదర్శక తర్కాన్ని పరిచయం చేయడమే. అంటే, పునరావృత కోడ్ తరగతుల్లో (కోణాలు) ఉంచబడుతుంది మరియు కొన్ని షరతులు సంతృప్తి చెందినప్పుడు అంటారు. ఉదాహరణకు, నిర్దిష్ట పేరుతో ఒక పద్ధతిని కాల్ చేస్తున్నప్పుడు లేదా నిర్దిష్ట రకం యొక్క వేరియబుల్‌ని యాక్సెస్ చేస్తున్నప్పుడు. కోడ్ ఎక్కడ నుండి పిలవబడుతుందో వెంటనే స్పష్టంగా తెలియనందున కొన్నిసార్లు అంశాలు గందరగోళంగా ఉండవచ్చు, కానీ ఇది ఇప్పటికీ చాలా ఉపయోగకరమైన కార్యాచరణ. ముఖ్యంగా కాషింగ్ లేదా లాగింగ్ చేసినప్పుడు. మేము సాధారణ తరగతులకు అదనపు లాజిక్‌ను జోడించకుండా ఈ కార్యాచరణను జోడిస్తాము. సాధారణ నిర్మాణం కోసం కెంట్ బెక్ యొక్క నాలుగు నియమాలు:

1. వ్యక్తీకరణ - తరగతి ఉద్దేశం స్పష్టంగా వ్యక్తీకరించబడాలి. ఇది సరైన పేరు పెట్టడం, చిన్న పరిమాణం మరియు ఒకే-బాధ్యత సూత్రానికి కట్టుబడి ఉండటం ద్వారా సాధించబడుతుంది (దీనిని మేము క్రింద మరింత వివరంగా పరిశీలిస్తాము).
2. కనిష్ట సంఖ్యలో తరగతులు మరియు పద్ధతులు — తరగతులను వీలైనంత చిన్నగా మరియు తృటిలో దృష్టి కేంద్రీకరించాలనే మీ కోరికలో, మీరు చాలా దూరం వెళ్ళవచ్చు (ఫలితంగా షాట్‌గన్ సర్జరీ వ్యతిరేక నమూనా). ఈ సూత్రం సిస్టమ్‌ను కాంపాక్ట్‌గా ఉంచడానికి మరియు చాలా దూరం వెళ్లకుండా, సాధ్యమయ్యే ప్రతి చర్యకు ప్రత్యేక తరగతిని సృష్టించడానికి పిలుపునిస్తుంది.
3. డూప్లికేషన్ లేదు — డూప్లికేట్ కోడ్, ఇది గందరగోళాన్ని సృష్టిస్తుంది మరియు సబ్‌ప్టిమల్ సిస్టమ్ డిజైన్‌కు సూచనగా ఉంటుంది, ఇది సంగ్రహించబడుతుంది మరియు ప్రత్యేక స్థానానికి తరలించబడుతుంది.
4. అన్ని పరీక్షలను అమలు చేస్తుంది - అన్ని పరీక్షలలో ఉత్తీర్ణత సాధించే వ్యవస్థ నిర్వహించదగినది. ఏదైనా మార్పు పరీక్ష విఫలం కావడానికి కారణం కావచ్చు, ఒక పద్ధతి యొక్క అంతర్గత తర్కంలో మన మార్పు ఊహించని రీతిలో సిస్టమ్ యొక్క ప్రవర్తనను కూడా మార్చిందని మాకు వెల్లడిస్తుంది.

SOLID

వ్యవస్థను రూపకల్పన చేసేటప్పుడు, బాగా తెలిసిన SOLID సూత్రాలను పరిగణనలోకి తీసుకోవడం విలువ:

S (ఒకే బాధ్యత), O (ఓపెన్-క్లోజ్డ్), L (లిస్కోవ్ ప్రత్యామ్నాయం), I (ఇంటర్ఫేస్ సెగ్రిగేషన్), D (డిపెండెన్సీ ఇన్వర్షన్).

మేము ప్రతి వ్యక్తిగత సూత్రంపై నివసించము. అది ఈ వ్యాసం యొక్క పరిధికి మించినది, కానీ మీరు ఇక్కడ మరింత చదవవచ్చు .

ఇంటర్ఫేస్

బాగా రూపొందించబడిన తరగతిని రూపొందించడంలో చాలా ముఖ్యమైన దశల్లో ఒకటి, మంచి సంగ్రహణను సూచించే చక్కగా రూపొందించబడిన ఇంటర్‌ఫేస్‌ను సృష్టించడం, తరగతి అమలు వివరాలను దాచడం మరియు ఏకకాలంలో ఒకదానితో ఒకటి స్పష్టంగా స్థిరంగా ఉండే పద్ధతుల సమూహాన్ని ప్రదర్శించడం. SOLID సూత్రాలలో ఒకదానిని నిశితంగా పరిశీలిద్దాం — ఇంటర్‌ఫేస్ విభజన: క్లయింట్లు (తరగతులు) వారు ఉపయోగించని అనవసరమైన పద్ధతులను అమలు చేయకూడదు. మరో మాటలో చెప్పాలంటే, ఇంటర్‌ఫేస్ యొక్క ఏకైక పనిని (ఇది ఒకే బాధ్యత సూత్రానికి చాలా సారూప్యంగా ఉంటుందని నేను భావిస్తున్నాను) అత్యంత తక్కువ సంఖ్యలో పద్ధతులతో ఇంటర్‌ఫేస్‌ను సృష్టించడం గురించి మాట్లాడుతున్నట్లయితే, బదులుగా రెండు చిన్న వాటిని సృష్టించడం మంచిది. ఒక ఉబ్బిన ఇంటర్ఫేస్. అదృష్టవశాత్తూ, ఒక తరగతి ఒకటి కంటే ఎక్కువ ఇంటర్‌ఫేస్‌లను అమలు చేయగలదు. మీ ఇంటర్‌ఫేస్‌లకు సరిగ్గా పేరు పెట్టాలని గుర్తుంచుకోండి: పేరు కేటాయించిన పనిని సాధ్యమైనంత ఖచ్చితంగా ప్రతిబింబించాలి. మరియు, వాస్తవానికి, ఇది చిన్నది, ఇది తక్కువ గందరగోళాన్ని కలిగిస్తుంది. డాక్యుమెంటేషన్ వ్యాఖ్యలు సాధారణంగా ఇంటర్‌ఫేస్ స్థాయిలో వ్రాయబడతాయి. ఈ వ్యాఖ్యలు ప్రతి పద్ధతిని ఏమి చేయాలి, దానికి ఎలాంటి వాదనలు అవసరం మరియు అది ఏమి తిరిగి వస్తుంది అనే దాని గురించి వివరాలను అందిస్తాయి.

తరగతి

చిత్ర మూలం

తరగతులు అంతర్గతంగా ఎలా ఏర్పాటు చేయబడతాయో చూద్దాం. లేదా, తరగతులు వ్రాసేటప్పుడు అనుసరించాల్సిన కొన్ని దృక్కోణాలు మరియు నియమాలు. నియమం ప్రకారం, ఒక తరగతి నిర్దిష్ట క్రమంలో వేరియబుల్స్ జాబితాతో ప్రారంభం కావాలి:

1. పబ్లిక్ స్టాటిక్ స్థిరాంకాలు;
2. ప్రైవేట్ స్టాటిక్ స్థిరాంకాలు;
3. ప్రైవేట్ ఉదాహరణ వేరియబుల్స్.

తదుపరి వివిధ కన్స్ట్రక్టర్లు వస్తాయి, తక్కువ ఆర్గ్యుమెంట్లు ఉన్న వారి నుండి ఎక్కువ ఉన్న వారి వరకు. వాటిని అత్యంత పబ్లిక్ నుండి అత్యంత ప్రైవేట్ వరకు పద్ధతులు అనుసరిస్తాయి. సాధారణంగా చెప్పాలంటే, మేము పరిమితం చేయాలనుకుంటున్న కొన్ని కార్యాచరణల అమలును దాచిపెట్టే ప్రైవేట్ పద్ధతులు చాలా దిగువన ఉన్నాయి.

తరగతి పరిమాణం

ఇప్పుడు నేను తరగతుల పరిమాణం గురించి మాట్లాడాలనుకుంటున్నాను. SOLID సూత్రాలలో ఒకదాన్ని గుర్తుచేసుకుందాం — ఒకే బాధ్యత సూత్రం. ప్రతి వస్తువుకు ఒకే ఒక ప్రయోజనం (బాధ్యత) ఉంటుందని మరియు దాని అన్ని పద్ధతుల యొక్క తర్కం దానిని సాధించడమే లక్ష్యంగా పెట్టుకుందని పేర్కొంది. ఇది పెద్ద, ఉబ్బిన తరగతులను (వాస్తవానికి దేవుని వస్తువు వ్యతిరేక నమూనా) నివారించమని చెబుతుంది మరియు అన్ని రకాల విభిన్న తర్కంతో కూడిన అనేక పద్ధతులు మనకు ఉంటే, దానిని ఒక తరగతిగా విభజించడం గురించి మనం ఆలోచించాలి. తార్కిక భాగాల జంట (తరగతులు). ఇది, కోడ్ యొక్క రీడబిలిటీని పెంచుతుంది, ఎందుకంటే ఏదైనా తరగతి యొక్క ఉజ్జాయింపు ప్రయోజనం మనకు తెలిస్తే, ప్రతి పద్ధతి యొక్క ఉద్దేశ్యాన్ని అర్థం చేసుకోవడానికి ఎక్కువ సమయం పట్టదు. అలాగే, తరగతి పేరుపై నిఘా ఉంచండి, అది కలిగి ఉన్న తర్కాన్ని ప్రతిబింబిస్తుంది. ఉదాహరణకు, మనకు దాని పేరులో 20+ పదాలు ఉన్న తరగతి ఉంటే, మనం రీఫ్యాక్టరింగ్ గురించి ఆలోచించాలి. ఏ స్వీయ-గౌరవనీయ తరగతి అయినా చాలా అంతర్గత వేరియబుల్స్ కలిగి ఉండకూడదు. వాస్తవానికి, ప్రతి పద్ధతి వాటిలో ఒకటి లేదా కొన్నింటితో పని చేస్తుంది, ఇది తరగతిలో చాలా సమన్వయాన్ని కలిగిస్తుంది (ఇది ఖచ్చితంగా ఉండాలి, ఎందుకంటే తరగతి ఏకీకృతంగా ఉండాలి). ఫలితంగా, తరగతి యొక్క సమన్వయాన్ని పెంచడం వలన తరగతి పరిమాణం తగ్గుతుంది మరియు తరగతుల సంఖ్య పెరుగుతుంది. ఇది కొంతమందికి చికాకు కలిగిస్తుంది, ఎందుకంటే మీరు నిర్దిష్టమైన పెద్ద టాస్క్ ఎలా పనిచేస్తుందో చూడడానికి క్లాస్ ఫైల్‌లను ఎక్కువగా పరిశీలించాలి. వీటన్నింటికీ మించి, ప్రతి తరగతి ఒక చిన్న మాడ్యూల్, ఇది ఇతరులకు తక్కువ సంబంధం కలిగి ఉండాలి. ఈ ఐసోలేషన్ తరగతికి అదనపు లాజిక్‌ను జోడించేటప్పుడు మనం చేయాల్సిన మార్పుల సంఖ్యను తగ్గిస్తుంది. ప్రతి పద్ధతి వాటిలో ఒకటి లేదా కొన్నింటితో పని చేస్తుంది, ఇది తరగతిలో చాలా సమన్వయాన్ని కలిగిస్తుంది (ఇది ఖచ్చితంగా ఉండాలి, ఎందుకంటే తరగతి ఏకీకృతంగా ఉండాలి). ఫలితంగా, తరగతి యొక్క సమన్వయాన్ని పెంచడం వలన తరగతి పరిమాణం తగ్గుతుంది మరియు తరగతుల సంఖ్య పెరుగుతుంది. ఇది కొంతమందికి చికాకు కలిగిస్తుంది, ఎందుకంటే మీరు నిర్దిష్టమైన పెద్ద టాస్క్ ఎలా పనిచేస్తుందో చూడడానికి క్లాస్ ఫైల్‌లను ఎక్కువగా పరిశీలించాలి. వీటన్నింటికీ మించి, ప్రతి తరగతి ఒక చిన్న మాడ్యూల్, ఇది ఇతరులకు తక్కువ సంబంధం కలిగి ఉండాలి. ఈ ఐసోలేషన్ తరగతికి అదనపు లాజిక్‌ను జోడించేటప్పుడు మనం చేయాల్సిన మార్పుల సంఖ్యను తగ్గిస్తుంది. ప్రతి పద్ధతి వాటిలో ఒకటి లేదా కొన్నింటితో పని చేస్తుంది, ఇది తరగతిలో చాలా సమన్వయాన్ని కలిగిస్తుంది (ఇది ఖచ్చితంగా ఉండాలి, ఎందుకంటే తరగతి ఏకీకృతంగా ఉండాలి). ఫలితంగా, తరగతి యొక్క సమన్వయాన్ని పెంచడం వలన తరగతి పరిమాణం తగ్గుతుంది మరియు తరగతుల సంఖ్య పెరుగుతుంది. ఇది కొంతమందికి చికాకు కలిగిస్తుంది, ఎందుకంటే మీరు నిర్దిష్టమైన పెద్ద టాస్క్ ఎలా పనిచేస్తుందో చూడడానికి క్లాస్ ఫైల్‌లను ఎక్కువగా పరిశీలించాలి. వీటన్నింటికీ మించి, ప్రతి తరగతి ఒక చిన్న మాడ్యూల్, ఇది ఇతరులకు తక్కువ సంబంధం కలిగి ఉండాలి. ఈ ఐసోలేషన్ తరగతికి అదనపు లాజిక్‌ను జోడించేటప్పుడు మనం చేయాల్సిన మార్పుల సంఖ్యను తగ్గిస్తుంది. s సంయోగం తరగతి పరిమాణంలో తగ్గింపుకు దారితీస్తుంది మరియు, వాస్తవానికి, తరగతుల సంఖ్య పెరుగుతుంది. ఇది కొంతమందికి చికాకు కలిగిస్తుంది, ఎందుకంటే మీరు నిర్దిష్టమైన పెద్ద టాస్క్ ఎలా పనిచేస్తుందో చూడడానికి క్లాస్ ఫైల్‌లను ఎక్కువగా పరిశీలించాలి. వీటన్నింటికీ మించి, ప్రతి తరగతి ఒక చిన్న మాడ్యూల్, ఇది ఇతరులకు తక్కువ సంబంధం కలిగి ఉండాలి. ఈ ఐసోలేషన్ తరగతికి అదనపు లాజిక్‌ను జోడించేటప్పుడు మనం చేయాల్సిన మార్పుల సంఖ్యను తగ్గిస్తుంది. s సంయోగం తరగతి పరిమాణంలో తగ్గింపుకు దారితీస్తుంది మరియు, వాస్తవానికి, తరగతుల సంఖ్య పెరుగుతుంది. ఇది కొంతమందికి చికాకు కలిగిస్తుంది, ఎందుకంటే మీరు నిర్దిష్టమైన పెద్ద టాస్క్ ఎలా పనిచేస్తుందో చూడడానికి క్లాస్ ఫైల్‌లను ఎక్కువగా పరిశీలించాలి. వీటన్నింటికీ మించి, ప్రతి తరగతి ఒక చిన్న మాడ్యూల్, ఇది ఇతరులకు తక్కువ సంబంధం కలిగి ఉండాలి. ఈ ఐసోలేషన్ తరగతికి అదనపు లాజిక్‌ను జోడించేటప్పుడు మనం చేయాల్సిన మార్పుల సంఖ్యను తగ్గిస్తుంది.

వస్తువులు

ఎన్కప్సులేషన్

ఇక్కడ మనం మొదట OOP సూత్రం గురించి మాట్లాడుతాము: ఎన్‌క్యాప్సులేషన్. అమలును దాచడం అనేది వేరియబుల్స్‌ను ఇన్సులేట్ చేయడానికి ఒక పద్ధతిని సృష్టించడం కాదు (వ్యక్తిగత పద్ధతులు, గెట్టర్‌లు మరియు సెట్టర్‌ల ద్వారా యాక్సెస్‌ను ఆలోచన లేకుండా పరిమితం చేయడం మంచిది కాదు, ఎందుకంటే ఎన్‌క్యాప్సులేషన్ పాయింట్ మొత్తం పోతుంది). యాక్సెస్‌ను దాచడం అనేది నైరూప్యతలను రూపొందించడానికి ఉద్దేశించబడింది, అంటే, మా డేటాతో పని చేయడానికి మేము ఉపయోగించే భాగస్వామ్య కాంక్రీట్ పద్ధతులను తరగతి అందిస్తుంది. మరియు మేము ఈ డేటాతో ఎలా పని చేస్తున్నామో వినియోగదారు ఖచ్చితంగా తెలుసుకోవలసిన అవసరం లేదు - ఇది పని చేస్తుంది మరియు ఇది సరిపోతుంది.

డిమీటర్ యొక్క చట్టం

మేము డిమీటర్ యొక్క నియమాన్ని కూడా పరిగణించవచ్చు: ఇది తరగతి మరియు పద్ధతి స్థాయిలో సంక్లిష్టతను నిర్వహించడంలో సహాయపడే చిన్న నియమాల సమితి. మన దగ్గర కార్ ఆబ్జెక్ట్ ఉందని అనుకుందాం, దానికి మూవ్(ఆబ్జెక్ట్ ఆర్గ్1, ఆబ్జెక్ట్ ఆర్గ్2) మెథడ్ ఉంది. డిమీటర్ చట్టం ప్రకారం, ఈ పద్ధతి కాల్ చేయడానికి పరిమితం చేయబడింది:

• కారు వస్తువు యొక్క పద్ధతులు (ఇతర మాటలలో, "ఈ" వస్తువు);
• తరలింపు పద్ధతిలో సృష్టించబడిన వస్తువుల పద్ధతులు ;
• ఆర్గ్యుమెంట్‌లుగా ఆమోదించబడిన వస్తువుల పద్ధతులు ( arg1 , arg2 );
• అంతర్గత కార్ వస్తువుల పద్ధతులు (మళ్ళీ, "ఇది").

మరో మాటలో చెప్పాలంటే, డిమీటర్ యొక్క చట్టం అనేది తల్లిదండ్రులు పిల్లలతో చెప్పేది: "మీరు మీ స్నేహితులతో మాట్లాడవచ్చు, కానీ అపరిచితులతో కాదు".

డేటా నిర్మాణం

డేటా స్ట్రక్చర్ అనేది సంబంధిత అంశాల సమాహారం. ఆబ్జెక్ట్‌ను డేటా స్ట్రక్చర్‌గా పరిగణించేటప్పుడు, పద్ధతులు పనిచేసే డేటా ఎలిమెంట్‌ల సమితి ఉంటుంది. ఈ పద్ధతుల ఉనికిని పరోక్షంగా ఊహించబడింది. అంటే, డేటా స్ట్రక్చర్ అనేది ఒక వస్తువు, దీని ఉద్దేశ్యం నిల్వ చేయబడిన డేటాను నిల్వ చేయడం మరియు పని చేయడం (ప్రాసెస్ చేయడం). సాధారణ వస్తువు నుండి దాని ప్రధాన వ్యత్యాసం ఏమిటంటే, ఒక సాధారణ ఆబ్జెక్ట్ అనేది ఉనికిలో ఉన్నట్లు ఊహించిన డేటా మూలకాలపై పనిచేసే పద్ధతుల సమాహారం. నీకు అర్ధమైనదా? సాధారణ వస్తువు యొక్క ప్రధాన అంశం పద్ధతులు. అంతర్గత వేరియబుల్స్ వాటి సరైన ఆపరేషన్‌ను సులభతరం చేస్తాయి. కానీ డేటా నిర్మాణంలో, నిల్వ చేయబడిన డేటా మూలకాలతో మీ పనికి మద్దతు ఇచ్చే పద్ధతులు ఉన్నాయి, అవి ఇక్కడ చాలా ముఖ్యమైనవి. ఒక రకమైన డేటా నిర్మాణం అనేది డేటా బదిలీ వస్తువు (DTO). ఇది పబ్లిక్ వేరియబుల్స్‌తో కూడిన తరగతి మరియు డేటాబేస్‌లతో పనిచేసేటప్పుడు డేటాను బదిలీ చేయడానికి, సాకెట్‌ల నుండి సందేశాలను అన్వయించడానికి మొదలైన పద్ధతులు (లేదా చదవడానికి/వ్రాయడానికి మాత్రమే పద్ధతులు) ఉపయోగించబడవు. డేటా సాధారణంగా అటువంటి వస్తువులలో ఎక్కువ కాలం నిల్వ చేయబడదు. ఇది దాదాపు వెంటనే మా అప్లికేషన్ పనిచేసే ఎంటిటీ రకానికి మార్చబడుతుంది. ఒక ఎంటిటీ, క్రమంగా, డేటా నిర్మాణం కూడా, కానీ అప్లికేషన్ యొక్క వివిధ స్థాయిలలో వ్యాపార తర్కంలో పాల్గొనడం దీని ఉద్దేశ్యం. DTO యొక్క ఉద్దేశ్యం అప్లికేషన్ నుండి/దానికి డేటాను రవాణా చేయడం. DTO యొక్క ఉదాహరణ: అనేది కూడా ఒక డేటా స్ట్రక్చర్, అయితే అప్లికేషన్ యొక్క వివిధ స్థాయిలలో వ్యాపార తర్కంలో పాల్గొనడం దీని ఉద్దేశ్యం. DTO యొక్క ఉద్దేశ్యం అప్లికేషన్ నుండి/దానికి డేటాను రవాణా చేయడం. DTO యొక్క ఉదాహరణ: అనేది కూడా ఒక డేటా స్ట్రక్చర్, అయితే అప్లికేషన్ యొక్క వివిధ స్థాయిలలో వ్యాపార తర్కంలో పాల్గొనడం దీని ఉద్దేశ్యం. DTO యొక్క ఉద్దేశ్యం అప్లికేషన్ నుండి/దానికి డేటాను రవాణా చేయడం. DTO యొక్క ఉదాహరణ:

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

ప్రతిదీ తగినంత స్పష్టంగా కనిపిస్తుంది, కానీ ఇక్కడ మేము హైబ్రిడ్ల ఉనికి గురించి తెలుసుకుంటాము. హైబ్రిడ్‌లు అనేవి ముఖ్యమైన తర్కాన్ని నిర్వహించడానికి, అంతర్గత అంశాలను నిల్వ చేయడానికి మరియు యాక్సెస్‌సర్ (గెట్/సెట్) పద్ధతులను కలిగి ఉండే పద్ధతులను కలిగి ఉండే వస్తువులు. ఇటువంటి వస్తువులు గజిబిజిగా ఉంటాయి మరియు కొత్త పద్ధతులను జోడించడం కష్టతరం చేస్తాయి. మీరు వాటిని నివారించాలి, ఎందుకంటే అవి దేనికి సంబంధించినవో స్పష్టంగా తెలియలేదు — మూలకాలను నిల్వ చేయాలా లేదా తర్కాన్ని అమలు చేయాలా?

వేరియబుల్స్ సృష్టించే సూత్రాలు

వేరియబుల్స్ గురించి కొంచెం ఆలోచించండి. మరింత ప్రత్యేకంగా, వాటిని సృష్టించేటప్పుడు ఏ సూత్రాలు వర్తిస్తాయి అనే దాని గురించి ఆలోచించండి:

1. ఆదర్శవంతంగా, మీరు దానిని ఉపయోగించే ముందు వేరియబుల్‌ను ప్రకటించి, ప్రారంభించాలి (ఒకటి సృష్టించి దాని గురించి మరచిపోకండి).
2. వీలైనప్పుడల్లా, ప్రారంభించిన తర్వాత వాటి విలువ మారకుండా నిరోధించడానికి వేరియబుల్‌లను ఫైనల్‌గా ప్రకటించండి.
3. కౌంటర్ వేరియబుల్స్ గురించి మరచిపోకండి, వీటిని మనం సాధారణంగా లూప్ కోసం ఉపయోగిస్తాము . అంటే, వాటిని సున్నా చేయడం మర్చిపోవద్దు. లేకుంటే మన లాజిక్కులన్నీ బద్దలవుతాయి.
4. మీరు కన్స్ట్రక్టర్‌లో వేరియబుల్స్‌ను ప్రారంభించేందుకు ప్రయత్నించాలి.
5. ఆబ్జెక్ట్‌ని రిఫరెన్స్‌తో లేదా లేకుండా ఉపయోగించడం మధ్య ఎంపిక ఉంటే ( కొత్త SomeObject() ), లేకుండా ఎంపిక చేసుకోండి, ఎందుకంటే ఆ వస్తువును ఉపయోగించిన తర్వాత అది తదుపరి చెత్త సేకరణ చక్రంలో తొలగించబడుతుంది మరియు దాని వనరులు వృధా కావు.
6. వేరియబుల్ జీవితకాలం (వేరియబుల్ యొక్క సృష్టి మరియు చివరిసారి సూచించబడిన దాని మధ్య దూరం) వీలైనంత తక్కువగా ఉంచండి.
7. లూప్‌లో ఉపయోగించిన వేరియబుల్స్‌ను లూప్‌ని కలిగి ఉన్న పద్ధతి ప్రారంభంలో కాకుండా లూప్‌కు ముందు ప్రారంభించండి.
8. ఎల్లప్పుడూ అత్యంత పరిమిత పరిధితో ప్రారంభించండి మరియు అవసరమైనప్పుడు మాత్రమే విస్తరించండి (మీరు వేరియబుల్‌ను వీలైనంత స్థానికంగా చేయడానికి ప్రయత్నించాలి).
9. ప్రతి వేరియబుల్‌ను ఒక ప్రయోజనం కోసం మాత్రమే ఉపయోగించండి.
10. దాచిన ప్రయోజనంతో వేరియబుల్‌లను నివారించండి, ఉదా. రెండు టాస్క్‌ల మధ్య వేరియబుల్ స్ప్లిట్ — అంటే వాటిలో ఒకదానిని పరిష్కరించడానికి దాని రకం తగినది కాదని అర్థం.

పద్ధతులు

"స్టార్ వార్స్: ఎపిసోడ్ III - రివెంజ్ ఆఫ్ ది సిత్" (2005) చిత్రం నుండి

నేరుగా మన తర్కం అమలుకు, అంటే పద్ధతులకు వెళ్దాం.

1. నియమం # 1 - కాంపాక్ట్‌నెస్. ఆదర్శవంతంగా, ఒక పద్ధతి 20 లైన్లను మించకూడదు. దీనర్థం, పబ్లిక్ పద్ధతి గణనీయంగా "ఉబ్బిపోతే", మీరు తర్కాన్ని వేరు చేసి, దానిని ప్రత్యేక ప్రైవేట్ పద్ధతుల్లోకి తరలించడం గురించి ఆలోచించాలి.

2. నియమం #2 — if , else , while మరియు ఇతర స్టేట్‌మెంట్‌లు భారీగా సమూహ బ్లాక్‌లను కలిగి ఉండకూడదు: చాలా గూడు చేయడం వలన కోడ్ యొక్క రీడబిలిటీ గణనీయంగా తగ్గుతుంది. ఆదర్శవంతంగా, మీరు రెండు కంటే ఎక్కువ సమూహ {} బ్లాక్‌లను కలిగి ఉండకూడదు .

   మరియు ఈ బ్లాక్‌లలో కోడ్‌ను కాంపాక్ట్ మరియు సరళంగా ఉంచడం కూడా అవసరం.

3. నియమం #3 — ఒక పద్ధతి ఒక ఆపరేషన్ మాత్రమే చేయాలి. అంటే, ఒక పద్ధతి అన్ని రకాల సంక్లిష్ట తర్కాన్ని ప్రదర్శిస్తే, మేము దానిని ఉపపద్ధతులుగా విభజిస్తాము. ఫలితంగా, పద్ధతి కూడా ఒక ముఖభాగం అవుతుంది, దీని ఉద్దేశ్యం అన్ని ఇతర కార్యకలాపాలను సరైన క్రమంలో కాల్ చేయడం.

   కానీ ఆపరేషన్ ఒక ప్రత్యేక పద్ధతిలో ఉంచడానికి చాలా సులభం అనిపిస్తే? నిజమే, కొన్నిసార్లు పిచ్చుకలపై ఫిరంగిని కాల్చినట్లు అనిపించవచ్చు, కానీ చిన్న పద్ధతులు అనేక ప్రయోజనాలను అందిస్తాయి:

   • మెరుగైన కోడ్ గ్రహణశక్తి;
   • అభివృద్ధి చెందుతున్న కొద్దీ పద్ధతులు మరింత క్లిష్టంగా మారతాయి. ఒక పద్ధతి ప్రారంభించడం సులభం అయితే, దాని కార్యాచరణను క్లిష్టతరం చేయడం కొంచెం సులభం అవుతుంది;
   • అమలు వివరాలు దాచబడ్డాయి;
   • సులభమైన కోడ్ పునర్వినియోగం;
   • మరింత నమ్మదగిన కోడ్.

4. స్టెప్‌డౌన్ నియమం — కోడ్‌ను పై నుండి క్రిందికి చదవాలి: మీరు ఎంత తక్కువగా చదివితే అంత లోతుగా మీరు తర్కాన్ని పరిశోధిస్తారు. మరియు వైస్ వెర్సా, మీరు ఎంత ఎక్కువ వెళ్తారో, పద్ధతులు మరింత వియుక్తంగా ఉంటాయి. ఉదాహరణకు, స్విచ్ స్టేట్‌మెంట్‌లు కాంపాక్ట్ కానివి మరియు అవాంఛనీయమైనవి, కానీ మీరు స్విచ్‌ని ఉపయోగించకుండా ఉండలేకపోతే, మీరు దానిని వీలైనంత తక్కువగా, అత్యల్ప-స్థాయి పద్ధతులకు తరలించడానికి ప్రయత్నించాలి.

5. పద్ధతి వాదనలు — ఆదర్శ సంఖ్య ఏమిటి? ఆదర్శవంతంగా, ఏదీ లేదు :) కానీ అది నిజంగా జరుగుతుందా? అంటే, మీరు వీలైనంత తక్కువ వాదనలను కలిగి ఉండటానికి ప్రయత్నించాలి, ఎందుకంటే తక్కువ సంఖ్యలో ఉంటే, ఒక పద్ధతిని ఉపయోగించడం సులభం మరియు దానిని పరీక్షించడం సులభం. సందేహాస్పదంగా ఉన్నప్పుడు, పెద్ద సంఖ్యలో ఇన్‌పుట్ పారామితులతో పద్ధతిని ఉపయోగించడం కోసం అన్ని దృశ్యాలను ఊహించడానికి ప్రయత్నించండి.

6. అదనంగా, బూలియన్ ఫ్లాగ్‌ను ఇన్‌పుట్ పారామీటర్‌గా కలిగి ఉన్న పద్ధతులను వేరు చేయడం మంచిది, ఎందుకంటే ఈ పద్ధతి ఒకటి కంటే ఎక్కువ ఆపరేషన్‌లను చేస్తుందని సూచిస్తుంది (నిజమైతే, ఒక పని చేయండి; తప్పు అయితే, మరొకటి చేయండి). నేను పైన వ్రాసినట్లు, ఇది మంచిది కాదు మరియు వీలైతే నివారించాలి.

7. ఒక పద్ధతికి పెద్ద సంఖ్యలో ఇన్‌పుట్ పారామితులు ఉంటే (అత్యంత 7, కానీ మీరు నిజంగా 2-3 తర్వాత ఆలోచించడం ప్రారంభించాలి), కొన్ని వాదనలు ప్రత్యేక వస్తువుగా వర్గీకరించబడాలి.

8. అనేక సారూప్య (ఓవర్‌లోడెడ్) పద్ధతులు ఉంటే, అదే క్రమంలో ఒకే విధమైన పారామితులను తప్పనిసరిగా పాస్ చేయాలి: ఇది చదవడానికి మరియు వినియోగాన్ని మెరుగుపరుస్తుంది.

9. మీరు ఒక పద్ధతికి పారామితులను పాస్ చేసినప్పుడు, అవన్నీ ఉపయోగించబడుతున్నాయని మీరు ఖచ్చితంగా నిర్ధారించుకోవాలి, లేకపోతే మీకు అవి ఎందుకు అవసరం? ఇంటర్ఫేస్ నుండి ఉపయోగించని పారామితులను కత్తిరించండి మరియు దానితో పూర్తి చేయండి.

10. ప్రయత్నించండి/క్యాచ్ ప్రకృతిలో చాలా అందంగా కనిపించడం లేదు, కాబట్టి దీనిని ప్రత్యేక ఇంటర్మీడియట్ పద్ధతికి తరలించడం మంచిది (మినహాయింపులను నిర్వహించడానికి ఒక పద్ధతి):

    
    public void exceptionHandling(SomeObject obj) {
        try {  
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    

నేను పైన డూప్లికేట్ కోడ్ గురించి మాట్లాడాను, కానీ మరోసారి పునరావృతం చేస్తాను: మనకు పునరావృతమయ్యే కోడ్‌తో రెండు పద్ధతులు ఉంటే, మనం దానిని ప్రత్యేక పద్ధతికి తరలించాలి. ఇది పద్ధతి మరియు తరగతి రెండింటినీ మరింత కాంపాక్ట్ చేస్తుంది. పేర్లను నియంత్రించే నియమాల గురించి మర్చిపోవద్దు: తరగతులు, ఇంటర్‌ఫేస్‌లు, పద్ధతులు మరియు వేరియబుల్‌లకు సరిగ్గా పేరు పెట్టడం ఎలా అనే వివరాలు వ్యాసం యొక్క తదుపరి భాగంలో చర్చించబడతాయి. కానీ ఈ రోజు మీ కోసం నా దగ్గర ఉన్నది ఒక్కటే.