
8. தங்க சுத்தி
ஒரு தங்க சுத்தியல் என்பது ஒரு குறிப்பிட்ட தீர்வு உலகளவில் பொருந்தும் என்ற நம்பிக்கையால் வரையறுக்கப்பட்ட ஒரு எதிர்ப்பு வடிவமாகும். எடுத்துக்காட்டுகள்:-
ஒரு சிக்கலைச் சந்தித்து, சரியான தீர்விற்கான ஒரு வடிவத்தைக் கண்டுபிடித்த பிறகு, ஒரு புரோகிராமர் குறிப்பிட்ட நிகழ்வுகளுக்கு பொருத்தமான தீர்வுகளைத் தேடுவதற்குப் பதிலாக, தற்போதைய மற்றும் அனைத்து எதிர்கால திட்டங்களுக்கும் இதைப் பயன்படுத்துகிறார்.
-
சில டெவலப்பர்கள் ஒருமுறை ஒரு குறிப்பிட்ட சூழ்நிலையில் ஒரு தற்காலிக சேமிப்பின் சொந்த மாறுபாட்டை உருவாக்கினர் (ஏனென்றால் வேறு எதுவும் பொருத்தமானதாக இல்லை). பின்னர், சிறப்பு கேச் லாஜிக் இல்லாத அடுத்த திட்டத்தில், அவர்கள் ஆயத்த நூலகங்களைப் பயன்படுத்துவதற்குப் பதிலாக மீண்டும் தங்கள் மாறுபாட்டைப் பயன்படுத்தினர் (உதாரணமாக, Ehcache). இதன் விளைவாக பிழைகள் மற்றும் இணக்கமின்மைகள், அத்துடன் நிறைய நேரத்தை வீணடித்தது மற்றும் வறுத்த நரம்புகள்.
இந்த எதிர்ப்பு முறைக்கு யார் வேண்டுமானாலும் விழலாம். நீங்கள் ஒரு தொடக்கக்காரராக இருந்தால், வடிவமைப்பு வடிவங்களைப் பற்றி உங்களுக்குத் தெரியாமல் இருக்கலாம். இது நீங்கள் தேர்ச்சி பெற்ற ஒரே வழியில் அனைத்து பிரச்சனைகளையும் தீர்க்க முயற்சி செய்ய வழிவகுக்கும். நாங்கள் நிபுணர்களைப் பற்றி பேசுகிறோம் என்றால், இதை தொழில்முறை சிதைவு அல்லது மேதாவித்தனம் என்று அழைக்கிறோம். உங்களுக்கான விருப்பமான வடிவமைப்பு வடிவங்கள் உங்களிடம் உள்ளன, மேலும் சரியான ஒன்றைப் பயன்படுத்துவதற்குப் பதிலாக, உங்களுக்குப் பிடித்ததைப் பயன்படுத்துகிறீர்கள்.
இந்த ஆபத்து மிகவும் சோகமான விளைவுகளை ஏற்படுத்தலாம் - மோசமான, நிலையற்ற, மற்றும் செயல்படுத்துவதைப் பராமரிக்க கடினமாக இருந்து திட்டத்தின் முழுமையான தோல்வி வரை. எல்லா நோய்களுக்கும் ஒரு மாத்திரை இல்லை என்பது போல, எல்லா சந்தர்ப்பங்களுக்கும் ஒரு வடிவமைப்பு முறை இல்லை.
9. முன்கூட்டிய தேர்வுமுறை
முன்கூட்டிய தேர்வுமுறை என்பது ஒரு எதிர்ப்பு வடிவமாகும், அதன் பெயர் தனக்குத்தானே பேசுகிறது.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 */
}
}
பின்வரும் கேள்விகளுக்கான பதில்களைத் தேட இந்த சங்கிலி நம்மைத் தூண்டுகிறது:
-
எத்தனை முறைகள்
VolkswagenAmarok
உள்ளன? -
அதிகபட்ச சுருக்கத்தை அடைய, கேள்விக்குறிக்கு பதிலாக எந்த வகையைச் செருக வேண்டும்:
? someObj = new VolkswagenAmarok(); someObj.brake();
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);
}
வசதியானது, எளிமையானது மற்றும் கச்சிதமானது, நீங்கள் நினைக்கவில்லையா? ஒரு நல்ல டெவலப்பரின் அறிகுறி, அவர் அல்லது அவள் எவ்வளவு அடிக்கடி வடிவங்களைப் பயன்படுத்துகிறார் என்பதும் அல்ல, மாறாக அவர் அல்லது அவள் எவ்வளவு அடிக்கடி எதிர்ப்பு வடிவங்களைத் தவிர்க்கிறார் என்பதுதான். அறியாமை மிக மோசமான எதிரி, ஏனென்றால் உங்கள் எதிரிகளை நீங்கள் பார்வையால் அறிந்து கொள்ள வேண்டும். சரி, இன்னைக்கு அவ்வளவுதான். அனைவருக்கும் நன்றி! :)
GO TO FULL VERSION