వ్యతిరేక నమూనాలు ఏమిటి? కొన్ని ఉదాహరణలను చూద్దాం (పార్ట్ 2)

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

8. గోల్డెన్ సుత్తి

బంగారు సుత్తి అనేది ఒక నిర్దిష్ట పరిష్కారం విశ్వవ్యాప్తంగా వర్తించే విశ్వాసం ద్వారా నిర్వచించబడిన వ్యతిరేక నమూనా. ఉదాహరణలు:

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

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

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

   ఈ ఆపద చాలా విచారకరమైన ఫలితాలను కలిగిస్తుంది - చెడు, అస్థిరత మరియు అమలును కొనసాగించడం కష్టం నుండి ప్రాజెక్ట్ పూర్తి వైఫల్యం వరకు. అన్ని వ్యాధులకు ఒకే మాత్ర లేనట్లే, అన్ని సందర్భాల్లోనూ ఒకే డిజైన్ నమూనా లేదు.

9. అకాల ఆప్టిమైజేషన్

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

10. స్పఘెట్టి కోడ్

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

public boolean someDifficultMethod(List<String> XMLAttrList) {
           ...
   int prefix = stringPool.getPrefixForQName(elementType);
   int elementURI;
   try {
       if (prefix == -1) {
        ...
           if (elementURI != -1) {
               stringPool.setURIForQName(...);
           }
       } else {
        ...
           if (elementURI == -1) {
           ...
           }
       }
   } catch (Exception e) {
       return false;
   }
   if (attrIndex != -1) {
       int index = attrList.getFirstAttr(attrIndex);
       while (index != -1) {
           int attName = attrList.getAttrName(index);
           if (!stringPool.equalNames(...)){
           ...
               if (attPrefix != namespacesPrefix) {
                   if (attPrefix == -1) {
                    ...
                   } else {
                       if (uri == -1) {
                       ...
                       }
                       stringPool.setURIForQName(attName, uri);
                   ...
                   }
                   if (elementDepth >= 0) {
                   ...
                   }
                   elementDepth++;
                   if (elementDepth == fElementTypeStack.length) {
                   ...
                   }
               ...
                   return contentSpecType == fCHILDRENSymbol;
               }
           }
       }
   }
}

ఇది భయంకరంగా ఉంది, కాదా? దురదృష్టవశాత్తూ, ఇది సర్వసాధారణమైన వ్యతిరేక నమూనా :( అటువంటి కోడ్ వ్రాసే వ్యక్తి కూడా భవిష్యత్తులో దానిని అర్థం చేసుకోలేరు. కోడ్‌ని చూసిన ఇతర డెవలపర్‌లు ఇలా అనుకుంటారు, "సరే, ఇది పనిచేస్తే, సరే - దానిని ముట్టుకోకపోవడమే మంచిది" కనిపిస్తుంది, మీరు దానిని పూర్తిగా లేదా కనీసం చాలా గందరగోళంగా ఉన్న భాగాలను రీఫ్యాక్టరింగ్ చేయాలి.సాధారణంగా, ప్రాజెక్ట్‌ను షెడ్యూల్ చేసేటప్పుడు, రీఫ్యాక్టరింగ్ కోసం సమయం కేటాయించబడుతుంది, ఉదాహరణకు, స్ప్రింట్ సమయంలో 30% రీఫ్యాక్టరింగ్ మరియు పరీక్షల కోసం. అయితే, ఇది ఊహిస్తుంది ఎటువంటి హడావిడి లేదని (కానీ అది ఎప్పుడు జరుగుతుంది).ఇక్కడ .

11. మేజిక్ సంఖ్యలు

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

12. కాపీ మరియు పేస్ట్ ప్రోగ్రామింగ్

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

public static int max(int[] array) {
   int max = 0;
   for(int i = 0; i < array.length; i++) {
       if (Math.abs(array[i]) > max){
           max = array[i];
       }
   }
   return max;
}

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

13. చక్రం తిరిగి ఆవిష్కరించడం

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

14. యో-యో సమస్య

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

public interface Technology {
   void turnOn();
}

రవాణా ఇంటర్‌ఫేస్ దానిని వారసత్వంగా పొందుతుంది:

public interface Transport extends Technology {
   boolean fillUp();
}

ఆపై మనకు మరొక ఇంటర్‌ఫేస్ ఉంది, గ్రౌండ్‌ట్రాన్స్‌పోర్ట్:

public interface GroundTransportation extends Transport {
   void startMove();
   void brake();
}

మరియు అక్కడ నుండి, మేము ఒక వియుక్త కార్ క్లాస్‌ని పొందుతాము:

public abstract class Car implements GroundTransportation {
   @Override
   public boolean fillUp() {
       /* some implementation */
       return true;
   }
   @Override
   public void turnOn() {
       /* some implementation */
   }
   public boolean openTheDoor() {
       /* some implementation */
       return true;
   }
   public abstract void fixCar();
}

తదుపరిది వియుక్త వోక్స్‌వ్యాగన్ తరగతి:

public abstract class Volkswagen extends Car {
   @Override
   public void startMove() {
       /* some implementation */
   }
   @Override
   public void brake() {
       /* some implementation */
   }
}

చివరకు, ఒక నిర్దిష్ట మోడల్:

public class VolkswagenAmarok extends Volkswagen {
   @Override
   public void fixCar(){
       /* some implementation */
   }
}

ఇలాంటి ప్రశ్నలకు సమాధానాల కోసం వేటాడేలా ఈ గొలుసు మనల్ని బలవంతం చేస్తుంది:

1. ఎన్ని పద్ధతులు VolkswagenAmarokఉన్నాయి?

2. గరిష్ట సంగ్రహణను సాధించడానికి ప్రశ్న గుర్తుకు బదులుగా ఏ రకాన్ని చొప్పించాలి:

   
   ? someObj = new VolkswagenAmarok();
          someObj.brake();
   

అటువంటి ప్రశ్నలకు త్వరగా సమాధానం ఇవ్వడం కష్టం — మనం పరిశీలించి, పరిశోధించాల్సిన అవసరం ఉంది మరియు గందరగోళానికి గురికావడం సులభం. మరియు అన్ని రకాల ఓవర్‌లోడ్‌లు మరియు ఓవర్‌రైడ్‌లతో సోపానక్రమం చాలా పెద్దదిగా, పొడవుగా మరియు మరింత క్లిష్టంగా ఉంటే ఏమి చేయాలి? అధిక ఫ్రాగ్మెంటేషన్ కారణంగా మనకు ఉండే నిర్మాణం అస్పష్టంగా ఉంటుంది. అనవసరమైన విభజనలను తగ్గించడం ఉత్తమ పరిష్కారం. మా విషయంలో, మేము టెక్నాలజీ → కార్ → వోక్స్‌వ్యాగన్ అమరోక్‌ను వదిలివేస్తాము.

15. ప్రమాదవశాత్తు సంక్లిష్టత

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

public void createDescriptionForElement(ServiceType type, Long languageId, Long serviceId, String description)throws Exception {
   switch (type){
       case CAR:
           jdbcTemplate.update(CREATE_RELATION_WITH_CAR, languageId, serviceId, description);
       case USER:
           jdbcTemplate.update(CREATE_RELATION_WITH_USER, languageId, serviceId, description);
       case FILE:
           jdbcTemplate.update(CREATE_RELATION_WITH_FILE, languageId, serviceId, description);
       case PLAN:
           jdbcTemplate.update(CREATE_RELATION_WITH_PLAN, languageId, serviceId, description);
       case CUSTOMER:
           jdbcTemplate.update(CREATE_RELATION_WITH_CUSTOMER, languageId, serviceId, description);
       default:
           throw new Exception();
   }
}

మరియు తదనుగుణంగా, మనకు ఈ ఎన్యూమ్ ఉంది:

public enum ServiceType {
   CAR(),
   USER(),
   FILE(),
   PLAN(),
   CUSTOMER()
}

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

@Getter
@AllArgsConstructor
public enum ServiceType {
   CAR("cars_descriptions", "car_id"),
   USER("users_descriptions", "user_id"),
   FILE("files_descriptions", "file_id"),
   PLAN("plans_descriptions", "plan_id"),
   CUSTOMER("customers_descriptions", "customer_id");
   private String tableName;
   private String columnName;
}

ఇప్పుడు ప్రతి రకానికి దాని టేబుల్ యొక్క అసలు ఫీల్డ్‌ల పేర్లు ఉన్నాయి. ఫలితంగా, వివరణను సృష్టించే పద్ధతి:

private static final String CREATE_RELATION_WITH_SERVICE = "INSERT INTO %s(language_id, %s, description) VALUES (?, ?, ?)";
public void createDescriptionForElement(ServiceType type, Long languageId, Long serviceId, String description) {
   jdbcTemplate.update(String.format(CREATE_RELATION_WITH_SERVICE, type.getTableName(), type.getColumnName()), languageId, serviceId, description);
   }

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