எதிர்ப்பு வடிவங்கள் என்றால் என்ன? சில உதாரணங்களைப் பார்ப்போம் (பகுதி 2)

எதிர்ப்பு வடிவங்கள் என்றால் என்ன? சில எடுத்துக்காட்டுகளைப் பார்ப்போம் (பாகம் 1) இன்று நாம் மிகவும் பிரபலமான எதிர்ப்பு வடிவங்களைப் பற்றிய எங்கள் மதிப்பாய்வைத் தொடர்கிறோம். முதல் பகுதியை நீங்கள் தவறவிட்டால், இதோ . எனவே, வடிவமைப்பு வடிவங்கள் சிறந்த நடைமுறைகள். வேறு வார்த்தைகளில் கூறுவதானால், அவை குறிப்பிட்ட சிக்கல்களைத் தீர்ப்பதற்கான நல்ல, நேர சோதனை வழிகளின் எடுத்துக்காட்டுகள். இதையொட்டி, பல்வேறு பிரச்சனைகளை (தீய வடிவங்கள்) தீர்க்கும் போது ஏற்படும் ஆபத்துகள் அல்லது தவறுகளின் வடிவங்கள் என்ற பொருளில், எதிர்ப்பு வடிவங்கள் அவற்றின் நேர் எதிரானவை. அடுத்த மென்பொருள் மேம்பாட்டு எதிர்ப்பு வடிவத்திற்குச் செல்வோம்.

8. தங்க சுத்தி

ஒரு தங்க சுத்தியல் என்பது ஒரு குறிப்பிட்ட தீர்வு உலகளவில் பொருந்தும் என்ற நம்பிக்கையால் வரையறுக்கப்பட்ட ஒரு எதிர்ப்பு வடிவமாகும். எடுத்துக்காட்டுகள்:

1. ஒரு சிக்கலைச் சந்தித்து, சரியான தீர்விற்கான ஒரு வடிவத்தைக் கண்டுபிடித்த பிறகு, ஒரு புரோகிராமர் குறிப்பிட்ட நிகழ்வுகளுக்கு பொருத்தமான தீர்வுகளைத் தேடுவதற்குப் பதிலாக, தற்போதைய மற்றும் அனைத்து எதிர்கால திட்டங்களுக்கும் இதைப் பயன்படுத்துகிறார்.

2. சில டெவலப்பர்கள் ஒருமுறை ஒரு குறிப்பிட்ட சூழ்நிலையில் ஒரு தற்காலிக சேமிப்பின் சொந்த மாறுபாட்டை உருவாக்கினர் (ஏனென்றால் வேறு எதுவும் பொருத்தமானதாக இல்லை). பின்னர், சிறப்பு கேச் லாஜிக் இல்லாத அடுத்த திட்டத்தில், அவர்கள் ஆயத்த நூலகங்களைப் பயன்படுத்துவதற்குப் பதிலாக மீண்டும் தங்கள் மாறுபாட்டைப் பயன்படுத்தினர் (உதாரணமாக, Ehcache). இதன் விளைவாக பிழைகள் மற்றும் இணக்கமின்மைகள், அத்துடன் நிறைய நேரத்தை வீணடித்தது மற்றும் வறுத்த நரம்புகள்.

   இந்த எதிர்ப்பு முறைக்கு யார் வேண்டுமானாலும் விழலாம். நீங்கள் ஒரு தொடக்கக்காரராக இருந்தால், வடிவமைப்பு வடிவங்களைப் பற்றி உங்களுக்குத் தெரியாமல் இருக்கலாம். இது நீங்கள் தேர்ச்சி பெற்ற ஒரே வழியில் அனைத்து பிரச்சனைகளையும் தீர்க்க முயற்சி செய்ய வழிவகுக்கும். நாங்கள் நிபுணர்களைப் பற்றி பேசுகிறோம் என்றால், இதை தொழில்முறை சிதைவு அல்லது மேதாவித்தனம் என்று அழைக்கிறோம். உங்களுக்கான விருப்பமான வடிவமைப்பு வடிவங்கள் உங்களிடம் உள்ளன, மேலும் சரியான ஒன்றைப் பயன்படுத்துவதற்குப் பதிலாக, உங்களுக்குப் பிடித்ததைப் பயன்படுத்துகிறீர்கள்.

   இந்த ஆபத்து மிகவும் சோகமான விளைவுகளை ஏற்படுத்தலாம் - மோசமான, நிலையற்ற, மற்றும் செயல்படுத்துவதைப் பராமரிக்க கடினமாக இருந்து திட்டத்தின் முழுமையான தோல்வி வரை. எல்லா நோய்களுக்கும் ஒரு மாத்திரை இல்லை என்பது போல, எல்லா சந்தர்ப்பங்களுக்கும் ஒரு வடிவமைப்பு முறை இல்லை.

9. முன்கூட்டிய தேர்வுமுறை

முன்கூட்டிய தேர்வுமுறை என்பது ஒரு எதிர்ப்பு வடிவமாகும், அதன் பெயர் தனக்குத்தானே பேசுகிறது. "புரோகிராமர்கள் குறியீட்டில் உள்ள முக்கியமான இடங்களைப் பற்றி சிந்திக்கவும் கவலைப்படவும் அதிக நேரத்தை செலவிடுகிறார்கள், மேலும் அவற்றை மேம்படுத்த முயற்சி செய்கிறார்கள், இது அடுத்தடுத்த பிழைத்திருத்தம் மற்றும் ஆதரவை எதிர்மறையாக பாதிக்கிறது. 97% வழக்குகளில் தேர்வுமுறை பற்றி நாம் பொதுவாக மறந்துவிட வேண்டும். மேலும் , முன்கூட்டிய உகப்பாக்கம் என்பது எல்லா தீமைக்கும் ஆணிவேராகும். அதாவது, மீதமுள்ள 3% மீது நாம் கவனம் செலுத்த வேண்டும்." - டொனால்ட் நத் எடுத்துக்காட்டாக, ஒரு தரவுத்தளத்தில் முன்கூட்டியே குறியீடுகளைச் சேர்ப்பது. அது ஏன் மோசமானது? சரி, அது மோசமானது, குறியீடுகள் பைனரி மரமாக சேமிக்கப்படுகின்றன. இதன் விளைவாக, ஒவ்வொரு முறையும் ஒரு புதிய மதிப்பு சேர்க்கப்பட்டு நீக்கப்படும் போது, ​​மரம் மீண்டும் கணக்கிடப்படும், மேலும் இது வளங்களையும் நேரத்தையும் பயன்படுத்துகிறது. எனவே, அவசரத் தேவையின் போது மட்டுமே குறியீடுகள் சேர்க்கப்பட வேண்டும் (உங்களிடம் அதிக அளவு தரவு இருந்தால் மற்றும் வினவல்கள் அதிக நேரம் எடுக்கும்) மற்றும் மிக முக்கியமான புலங்களுக்கு மட்டுமே (அடிக்கடி வினவப்படும் புலங்கள்).

10. ஸ்பாகெட்டி குறியீடு

ஸ்பாகெட்டி குறியீடானது , விதிவிலக்குகள், நிபந்தனைகள் மற்றும் சுழல்கள் போன்ற அனைத்து வகையான கிளைகளையும் கொண்ட, மோசமாக கட்டமைக்கப்பட்ட, குழப்பமான மற்றும் புரிந்துகொள்ள கடினமாக இருக்கும் குறியீட்டால் வரையறுக்கப்பட்ட ஒரு எதிர்ப்பு வடிவமாகும். முன்னதாக, கோட்டோ ஆபரேட்டர் இந்த எதிர்ப்பு வடிவத்தின் முக்கிய கூட்டாளியாக இருந்தது. Goto அறிக்கைகள் உண்மையில் இனி பயன்படுத்தப்படாது, இது பல தொடர்புடைய சிரமங்களையும் சிக்கல்களையும் மகிழ்ச்சியுடன் நீக்குகிறது.

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();
   

இது போன்ற கேள்விகளுக்கு விரைவாக பதிலளிப்பது கடினம் — நாம் ஒரு பார்வை மற்றும் விசாரணை செய்ய வேண்டும், மேலும் குழப்பமடைவது எளிது. அனைத்து வகையான சுமைகள் மற்றும் மேலெழுதுதல்களுடன், படிநிலை மிகவும் பெரியதாகவும், நீளமாகவும், மேலும் சிக்கலானதாகவும் இருந்தால் என்ன செய்வது? அதிகப்படியான துண்டு துண்டாக இருப்பதால் நம்மிடம் இருக்கும் கட்டமைப்பு மறைக்கப்படும். தேவையற்ற பிரிவினைகளைக் குறைப்பதே சிறந்த தீர்வாக இருக்கும். எங்கள் விஷயத்தில், நாங்கள் தொழில்நுட்பம் → கார் → VolkswagenAmarok ஐ விட்டுவிடுவோம்.

15. விபத்து சிக்கலானது

தேவையற்ற சிக்கலானது ஒரு எதிர்ப்பு வடிவமாகும், இதில் தேவையற்ற சிக்கல்கள் தீர்வுக்கு அறிமுகப்படுத்தப்படுகின்றன. "எந்த முட்டாளும் கணினியால் புரிந்து கொள்ளக்கூடிய குறியீட்டை எழுத முடியும். நல்ல புரோகிராமர்கள் மனிதர்கள் புரிந்துகொள்ளக்கூடிய குறியீட்டை எழுதுகிறார்கள்." - மார்ட்டின் ஃபோலர் எனவே சிக்கலானது என்ன? நிரலில் ஒவ்வொரு செயல்பாடும் செய்யப்படும் சிரமத்தின் அளவு என இது வரையறுக்கப்படுகிறது. ஒரு விதியாக, சிக்கலை இரண்டு வகைகளாகப் பிரிக்கலாம். முதல் வகையான சிக்கலானது ஒரு அமைப்பு கொண்டிருக்கும் செயல்பாடுகளின் எண்ணிக்கை. அதை ஒரே ஒரு வழியில் குறைக்க முடியும் - சில செயல்பாடுகளை அகற்றுவதன் மூலம். தற்போதுள்ள முறைகளை கண்காணிக்க வேண்டும். ஒரு முறை இனி பயன்படுத்தப்படாவிட்டாலோ அல்லது இன்னும் பயன்படுத்தப்பட்டாலோ, ஆனால் எந்த மதிப்பையும் கொண்டு வராமல் அகற்றப்பட வேண்டும். மேலும், பயன்பாட்டில் உள்ள அனைத்து முறைகளும் எவ்வாறு பயன்படுத்தப்படுகின்றன என்பதை நீங்கள் மதிப்பீடு செய்ய வேண்டும், முதலீடுகள் எங்கு பயனுள்ளதாக இருக்கும் (நிறைய குறியீட்டு மறுபயன்பாடு) மற்றும் நீங்கள் எதை வேண்டாம் என்று சொல்லலாம் என்பதைப் புரிந்துகொள்வதற்கு. இரண்டாவது வகை சிக்கலானது தேவையற்ற சிக்கலானது. ஒரு தொழில்முறை அணுகுமுறை மூலம் மட்டுமே குணப்படுத்த முடியும். "குளிர்ச்சியாக" ஏதாவது செய்வதற்கு பதிலாக (இளம் டெவலப்பர்கள் மட்டுமே இந்த நோய்க்கு ஆளாகவில்லை), முடிந்தவரை எளிமையாக எப்படி செய்வது என்று நீங்கள் சிந்திக்க வேண்டும், ஏனென்றால் சிறந்த தீர்வு எப்போதும் எளிமையானது. எடுத்துக்காட்டாக, பயனர் போன்ற சில நிறுவனங்களின் விளக்கங்களுடன் தொடர்புடைய சிறிய அட்டவணைகள் எங்களிடம் உள்ளன என்று வைத்துக்கொள்வோம்: எனவே, எங்களிடம் பயனரின் ஐடி, விளக்கம் செய்யப்பட்ட மொழியின் ஐடி மற்றும் விளக்கமே உள்ளது. இதேபோல், எங்களிடம் கார்கள், கோப்புகள், திட்டங்கள் மற்றும் வாடிக்கையாளர் அட்டவணைகளுக்கான துணை விளக்கங்கள் உள்ளன. அத்தகைய அட்டவணையில் புதிய மதிப்புகளைச் செருகுவது எப்படி இருக்கும்?

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);
   }

வசதியானது, எளிமையானது மற்றும் கச்சிதமானது, நீங்கள் நினைக்கவில்லையா? ஒரு நல்ல டெவலப்பரின் அறிகுறி, அவர் அல்லது அவள் எவ்வளவு அடிக்கடி வடிவங்களைப் பயன்படுத்துகிறார் என்பதும் அல்ல, மாறாக அவர் அல்லது அவள் எவ்வளவு அடிக்கடி எதிர்ப்பு வடிவங்களைத் தவிர்க்கிறார் என்பதுதான். அறியாமை மிக மோசமான எதிரி, ஏனென்றால் உங்கள் எதிரிகளை நீங்கள் பார்வையால் அறிந்து கொள்ள வேண்டும். சரி, இன்னைக்கு அவ்வளவுதான். அனைவருக்கும் நன்றி! :)