நமக்கு ஏன் OOP தேவை?

1. நிறுவனத்தின் வரலாறு

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

ஒரு காலத்தில் ஒரு சிறிய நிறுவனம் இண்டர்கலெக்டிக் கப்பல் சேவைகளை வழங்கியது.

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

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

அப்போதுதான் பிரச்சனைகள் ஆரம்பித்தன. அதிகமான மக்கள் இருந்தனர் , அவர்கள் ஒருவரையொருவர் வழிக்கு கொண்டு வரத் தொடங்கினர்.

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

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

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

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

ஏதாவது செய்ய வேண்டும், எனவே முதலாளி மோனோலிதிக் நிறுவனத்தை ஒரு சில துறைகளாக பிரிக்க முடிவு செய்தார். அவர் ஒரு கப்பல் துறை, ஒரு சந்தைப்படுத்தல் துறை, ஒரு கொள்முதல் துறை, ஒரு நிதி துறை மற்றும் ஒரு சரக்கு துறையை உருவாக்கினார். இனி யாரும் விண்கலத்தை வெறுமனே எடுத்துச் செல்ல முடியாது. கப்பல் துறையின் தலைவர் டெலிவரிகள் பற்றிய அனைத்து தகவல்களையும் பெற்றார் மற்றும் மிகவும் இலாபகரமான ஆர்டருடன் கப்பலை கூரியருக்கு வழங்கினார். கூடுதலாக, கிடங்கு கூரியர்களை அவர்கள் விரும்பும் எந்தப் பொருட்களையும் எடுத்துச் செல்ல அனுமதிக்கவில்லை. மாறாக, கிடங்கில் இருந்து பொருட்களை எடுப்பது ஒரு கட்டுப்படுத்தப்பட்ட செயலாக மாறியது. விரைவில் கொள்முதல் இருக்கும் என்று தெரிந்தால், சந்தைப்படுத்தல் பிரச்சாரத்திற்கு நிதித் துறை நிதியை வெளியிடாது. ஒவ்வொரு துறைக்கும் ஒரு பொது முகம் இருந்தது - துறைத் தலைவர்.ஒவ்வொரு துறையின் உள் கட்டமைப்பும் அதன் சொந்த வணிகமாக இருந்தது. ஒரு கூரியர் பொருட்களைப் பெற விரும்பினால், அவர் கிடங்கு மேலாளரிடம் சென்றார், கிடங்கிற்கு அல்ல. ஒரு புதிய ஆர்டர் வந்தால், அது கப்பல் துறையின் தலைவரால் பெறப்பட்டது ( public-facing representative) மற்றும் ஒரு கூரியர் ( someone not authorized to interact with the other departments) மூலம் அல்ல.

வேறு வார்த்தைகளில் கூறுவதானால், முதலாளி வளங்களை உள்ளடக்கிய வளங்களையும் செயல்களையும் குழுக்களாக (துறைகள்) ஒருங்கிணைத்தார் , மேலும் துறைகளின் உள் கட்டமைப்புகளில் மற்றவர்கள் தலையிடுவதையும் தடை செய்தார். துறைகளுக்கிடையேயான தொடர்புகள் ஒரு குறிப்பிட்ட நபரின் மூலம் செல்ல வேண்டும்.

OOP இன் பார்வையில் , இது நிரலை பொருள்களாகப் பிரிப்பதைத் தவிர வேறில்லை . முறைகள் மற்றும் மாறிகளின் ஒரு ஒற்றை நிரல் பொருள்களைக் கொண்ட ஒரு நிரலாக மாறும். மற்றும் பொருள்களுக்கு மாறிகள் மற்றும் முறைகள் உள்ளன.

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

இது அதன் தூய்மையான வடிவத்தில் பிரித்து வெற்றி பெறுகிறது.

2. புரோகிராம்கள் எவ்வாறு உருவாக்கப்படுகின்றன

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

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

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

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

இவை அனைத்திலிருந்தும் நாம் என்ன முடிவை எடுக்க முடியும்? தயாரிப்பின் உள் கட்டமைப்பு குறிப்பிடத்தக்க (மற்றும் சிறிய) மாற்றங்களை குறைந்தபட்ச மறுவேலையுடன் செய்ய அனுமதிக்கும் வகையில் பராமரிக்கப்பட வேண்டும்.

பொருள் ஒருங்கிணைப்பு

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

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

தளர்வான இணைப்பு கொள்கை

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

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

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

சுருக்கத்தின் கொள்கை

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

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