ఆబ్జెక్ట్ ఓరియెంటెడ్ ప్రోగ్రామింగ్ యొక్క 5 సూత్రాలు ఏమిటి

SOLID అనేది ఎక్రోనిం, ఇది ఆబ్జెక్ట్-ఓరియెంటెడ్ డిజైన్ (OOD లేదా OOP) యొక్క ఐదు సూత్రాలను సూచిస్తుంది. ఇవి నిర్వహించడానికి, నిర్వహించడానికి మరియు విస్తరించడానికి సులభమైన సాఫ్ట్‌వేర్‌ను రూపొందించడానికి డెవలపర్‌లు ఉపయోగించగల మార్గదర్శకాలు. ఈ భావనలను అర్థం చేసుకోవడం మిమ్మల్ని మంచి డెవలపర్‌గా చేస్తుంది మరియు సాఫ్ట్‌వేర్ నిర్వహణ సమస్యలను నివారించడంలో మీకు సహాయపడుతుంది. మంచి ప్రోగ్రామర్ అని అర్థం ఏమిటి?

సాఫ్ట్‌వేర్ ప్రోగ్రామింగ్‌లో కొంత అనుభవం ఉన్న ఎవరైనా వారి కెరీర్ మార్గం ఆధారంగా తీర్పు పారామితులను ఉపయోగించి ఇతరులు రాసిన సాఫ్ట్‌వేర్ కోడ్‌ను నిర్ణయిస్తారు.

నా వృత్తి జీవితంలో, నేను చాలా మంది డెవలపర్‌లను తెలుసు, మరియు నేను వేలాది కోడ్‌లను చూశాను మరియు డెవలపర్ యొక్క నైపుణ్యాన్ని అంచనా వేయవలసి వచ్చినప్పుడు నేను ప్రధానంగా రెండు అంశాలను చూస్తాను:

• కోడ్ చదవడంలో సరళత;
• వారి కోడ్ కాలక్రమేణా పని చేయడానికి మరియు అభివృద్ధి చెందడానికి ఎంత అవకాశం ఉంది.

అదృష్టవశాత్తూ, కోడింగ్‌లో మెరుగ్గా ఉండటాన్ని సులభతరం చేసే కొన్ని ప్రాథమిక అంశాలు లేదా సూత్రాలు ఉన్నాయి.

SOLID అనే ఎక్రోనిం అంటే:
S: ఒకే బాధ్యత సూత్రం
O: ఓపెన్-క్లోజ్డ్ సూత్రం
L: లిస్కోవ్ ప్రత్యామ్నాయ సూత్రం
I: ఇంటర్ఫేస్ విభజన యొక్క సూత్రం
D: డిపెండెన్సీల విలోమ సూత్రం

మొదటి SOLID సూత్రాన్ని పరిశీలిస్తే ప్రారంభిద్దాం, అవి

ఒకే బాధ్యత సూత్రం

ఒక తరగతి (లేదా మాడ్యూల్) మారడానికి, అభివృద్ధి చెందడానికి ఒకే ఒక కారణం ఉండాలి.

భావన చాలా సులభం, కానీ ఈ సరళతను సాధించడానికి అమలు మార్గం చాలా క్లిష్టంగా ఉంటుంది. ఒక తరగతి మారడానికి ఒకే ఒక కారణం ఉండాలి.

కానీ ఎందుకు? 

మార్చడానికి ఒకే ఒక కారణం ఉండటం ఎందుకు చాలా ముఖ్యం?

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

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

ఒక తరగతి లేదా మాడ్యూల్ కలిగి ఉన్న ఒక లక్షణాన్ని గుర్తించడం పరీక్షలను అమలు చేయడానికి చెక్‌లిస్ట్‌ను చూడటం కంటే చాలా క్లిష్టంగా ఉంటుంది. 

కానీ తక్కువ సాంకేతిక కోణం నుండి ఆలోచించటానికి ప్రయత్నిద్దాం, అనగా, మా తరగతి లేదా మాడ్యూల్ యొక్క వినియోగదారుని విశ్లేషించడానికి ప్రయత్నిద్దాం, అది ఎవరు ఉపయోగిస్తారు. మనం ఎల్లప్పుడూ గుర్తుంచుకోవలసిన ఒక ప్రాథమిక అంశం ఏమిటంటే, ఒక నిర్దిష్ట మాడ్యూల్ ద్వారా సేవలు అందించే మేము అభివృద్ధి చేసే అప్లికేషన్ లేదా సిస్టమ్ యొక్క వినియోగదారులు దానికి సవరణలను అభ్యర్థిస్తారు. పనిచేసిన వారు తరగతి లేదా మాడ్యూల్ మార్చమని అడుగుతారు. 

గుణకాలు మరియు వాటి ఉపయోగం యొక్క కొన్ని ఉదాహరణలు:

• నిర్వహణ మాడ్యూల్: వినియోగదారు డేటాబేస్ నిర్వాహకులు మరియు సాఫ్ట్‌వేర్ ఆర్కిటెక్ట్‌లతో రూపొందించబడింది.
• రిపోర్టింగ్ మాడ్యూల్: వినియోగదారు కార్యాలయ ఉద్యోగులు, అకౌంటెంట్లు మరియు ఉత్పత్తితో రూపొందించబడింది.
• పేరోల్ నిర్వహణ వ్యవస్థ కోసం చెల్లింపు లెక్కింపు మాడ్యూల్: వినియోగదారులు న్యాయవాదులు, నిర్వాహకులు మరియు అకౌంటెంట్లను చేర్చవచ్చు.
• లైబ్రరీ నిర్వహణ వ్యవస్థ కోసం వచన శోధన మాడ్యూల్: వినియోగదారుని లైబ్రేరియన్ లేదా లైబ్రరీ యొక్క సందర్శకులు మరియు కస్టమర్లు ప్రాతినిధ్యం వహిస్తారు.

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

వ్యక్తులు లేదా వినియోగదారుల కంటే పాత్రలను గుర్తించడం మరింత సహేతుకమైనదిగా అనిపిస్తుంది.

అందువలన:

• సాఫ్ట్‌వేర్ సిస్టమ్ యొక్క ఉపయోగం defiమార్పుకు గల కారణాలను వివరిస్తుంది;
• బాధ్యత అనేది ఒక నిర్దిష్ట నటుడి అవసరాలను, అంటే వ్యవస్థ యొక్క వినియోగదారుని సంతృప్తిపరిచే విధుల కుటుంబం;
• నటీనటులు, వినియోగదారు అవసరాలను తీర్చగల కార్యాచరణ యొక్క కుటుంబానికి మార్పు యొక్క మూలంగా మారుతుంది;
• వినియోగదారు అవసరాల పరిణామం, కార్యాచరణ యొక్క పరిణామానికి మార్గనిర్దేశం చేస్తుంది;

కొన్ని ఉదాహరణలు చూద్దాం

మనకు పుస్తక తరగతి ఉందని అనుకుందాం, అది పుస్తకం యొక్క భావనను మరియు దాని కార్యాచరణను కలుపుతుంది.

తరగతి పుస్తకం {

    ఫంక్షన్ getTitle () {

        తిరిగి “గొప్ప పుస్తకం”;

    }

    ఫంక్షన్ getAuthor () {

        తిరిగి “అలెశాండ్రో బారికో”;

    }

    ఫంక్షన్ తదుపరి పేజీ () {

        // తరువాతి పేజీ

    }

    ఫంక్షన్ ప్రింట్ ప్రస్తుత పేజీ () {

        ప్రతిధ్వని “ప్రస్తుత పేజీ యొక్క కంటెంట్”;

    }

}

ఇది చాలా సాధారణ తరగతి. మాకు ఒక పుస్తకం ఉంది, మరియు తరగతి మాకు టైటిల్ ఇవ్వగలదు, వారు మాకు రచయితను ఇవ్వగలరు మరియు వారు ముందుకు సాగవచ్చు. చివరగా, ఇది స్క్రీన్‌పై ప్రస్తుత పేజీని ప్రింట్ చేయగలదు. 

అయితే, ఒక చిన్న సమస్య ఉంది. 

పుస్తక వస్తువు నిర్వహణలో పాల్గొన్న నటుల గురించి ఆలోచిస్తే, వారు ఎవరు కావచ్చు? 

మేము ఇక్కడ ఇద్దరు వేర్వేరు నటుల గురించి సులభంగా ఆలోచించవచ్చు: పుస్తక నిర్వహణ (గా లైబ్రేరియన్) ఇ డేటా సమర్పణ విధానం (మేము వినియోగదారుకు కంటెంట్‌ను ఎలా బట్వాడా చేయాలనుకుంటున్నామో వంటివి: ఆన్-స్క్రీన్, గ్రాఫికల్ యూజర్ ఇంటర్ఫేస్, టెక్స్ట్-ఓన్లీ యూజర్ ఇంటర్ఫేస్, బహుశా ప్రింట్). 

అందువల్ల మాకు చాలా భిన్నమైన ఇద్దరు నటులు తరగతితో సంభాషిస్తున్నారు.

ఒక్కమాటలో చెప్పాలంటే, ఈ తరగతి వీటి మధ్య మిశ్రమాన్ని చేస్తుంది:

• వ్యాపార తర్కం 
• ప్రదర్శన 

ఇది ఒకే సమస్య సూత్రాన్ని (SRP) ఉల్లంఘించినందున ఇది సమస్య కావచ్చు. 

ఒకే బాధ్యత యొక్క సూత్రాన్ని గౌరవించడానికి మేము ఈ కోడ్‌ను ఎలా మెరుగుపరచగలం?

కింది కోడ్‌ను చూడండి:

తరగతి పుస్తకం {

    ఫంక్షన్ getTitle () {

        తిరిగి “ఓషినో మేరే”;

    }

    ఫంక్షన్ getAuthor () {

        తిరిగి “అలెశాండ్రో బారికో”;

    }

    ఫంక్షన్ మలుపు పేజీ () {

        // తరువాతి పేజీ

    }

    getCurrentPage () ఫంక్షన్ {

        ప్రతిధ్వని “ప్రస్తుత పేజీ యొక్క కంటెంట్”;

    }

}

ఇంటర్ఫేస్ ప్రింటర్ {

    ఫంక్షన్ ప్రింట్ పేజ్ ($ పేజీ);

}

తరగతి స్టాంపాలిబ్రో ప్రింటర్‌ను అమలు చేస్తుంది {

    ఫంక్షన్ ప్రింట్ పేజీలు ($ పేజీ) {

        ఎకో $ పేజీ;

    }

}

 

తరగతి HtmlPrinter ప్రింటర్‌ను అమలు చేస్తుంది {

    ఫంక్షన్ ప్రింట్ పేజీలు ($ పేజీ) {

        ఎకో ' '. $ పేజీ. ' ';

    }

}

ఈ చాలా సరళమైన ఉదాహరణ వ్యాపార తర్కం నుండి ప్రదర్శనను ఎలా వేరు చేయాలో చూపిస్తుంది మరియు SRP కి అనుగుణంగా ఇది మా ప్రాజెక్ట్ యొక్క వశ్యతలో గొప్ప ప్రయోజనాలను అందిస్తుంది.

మరొక ఉదాహరణ చూద్దాం:

ప్రెజెంటేషన్ నుండి ఒక వస్తువు తనను తాను సేవ్ చేసుకొని తిరిగి పొందగలిగినప్పుడు పై ఉదాహరణతో సమానమైన ఉదాహరణ.

తరగతి పుస్తకం {

    ఫంక్షన్ getTitle () {

        తిరిగి “ఓషినో మేరే”;

    }

    ఫంక్షన్ getAuthor () {

        తిరిగి “అలెశాండ్రో బారికో”;

    }

    ఫంక్షన్ మలుపు పేజీ () {

        // తరువాతి పేజీ

    }

    getCurrentPage () ఫంక్షన్ {

        "ప్రస్తుత పేజీ యొక్క కంటెంట్" తిరిగి;

    }

    ఫంక్షన్ సేవ్ () {

        $ filename = '/ పత్రాలు /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();

        file_put_contents ($ filename, serialize ($ this));

    }

}

మునుపటిలాగా, ఇక్కడ కూడా మేము విభిన్న నటులను గుర్తించగలము పుస్తక నిర్వహణ (గా లైబ్రేరియన్) ఇ పట్టుదల. మనం పేజీ నుండి పేజీకి వెళ్ళే విధానాన్ని మార్చాలనుకున్నప్పుడు, మేము ఈ తరగతిని మార్చాలి. మార్పుకు మనకు అనేక కారణాలు ఉండవచ్చు.

తరగతి పుస్తకం {

    ఫంక్షన్ getTitle () {

        తిరిగి “ఓషినో మేరే”;

    }

    ఫంక్షన్ getAuthor () {

        తిరిగి “అలెశాండ్రో బారికో”;

    }

    ఫంక్షన్ మలుపు పేజీ () {

        // తరువాతి పేజీ

    }

    getCurrentPage () ఫంక్షన్ {

        "ప్రస్తుత పేజీ యొక్క కంటెంట్" తిరిగి;

    }

}

తరగతి సింపుల్ ఫైల్‌పెర్సిస్టెన్స్ {

    ఫంక్షన్ సేవ్ (బుక్ $ బుక్) {

        $ filename = '/ పత్రాలు /'. $ పుస్తకం-> getTitle (). '-'. $ పుస్తకం-> getAuthor ();

        file_put_contents ($ ఫైల్ పేరు, సీరియలైజ్ ($ పుస్తకం));

    }

}

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

రెండవ సూత్రాన్ని చదవడం ద్వారా కొనసాగించండి ఓపెన్ / క్లోజ్డ్ ->

Ercole Palmeri