ವಿಕಿಪೀಡಿಯ

ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೆಡ್ ಪ್ರೊಗ್ರಾಮಿಂಗ್

ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ( OOP ) ಎನ್ನುವುದು ವಸ್ತುಗಳ ಅಂದರೆ ಆಬ್ಜೆಕ್ಟ್ ಗಳ ಪರಿಕಲ್ಪನೆಯ ಆಧಾರದ ಮೇಲೆ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾದರಿಯಾಗಿದೆ, [೧] ಇದು ಡೇಟಾ ಮತ್ತು ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ: ‍ಫೀಲ್ಡ್ ಗಳ ರೂಪದಲ್ಲಿ ಡೇಟಾ (ಸಾಮಾನ್ಯವಾಗಿ ಅಟ್ರಿಬ್ಯೂಟ್ ಗಳು ಅಥವಾ ಗುಣಲಕ್ಷಣಗಳು (ಪ್ರಾಪರ್ಟಿಗಳು) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ), ಮತ್ತು ಕಾರ್ಯವಿಧಾನಗಳ ರೂಪದಲ್ಲಿ ಕೋಡ್ (ಸಾಮಾನ್ಯವಾಗಿ ವಿಧಾನಗಳು ಅಥವಾ ಮೆಥೆಡ್ ಗಳು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ). OOP ನಲ್ಲಿ, ಕಂಪ್ಯೂಟರ್ ಪ್ರೋಗ್ರಾಮ್‌ಗಳನ್ನು ಒಂದಕ್ಕೊಂದು ಸಂವಹಿಸುವ ವಸ್ತುಗಳಿಂದ ತಯಾರಿಸುವ ಮೂಲಕ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. [೨] [೩]

ಕ್ಲಾಸ್ ನ UML ಸಂಕೇತ. ಈ ಬಟನ್ ಕ್ಲಾಸ್ ಡೇಟಾ ಮತ್ತು ಫಂಕ್ಷನ್ ಗಳಿಗಾಗಿ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಹೊಂದಿದೆ . ಇಂಹೆರಿಟೆನ್ಸ್ ನ ಮೂಲಕ, ಬಟನ್ ಕ್ಲಾಸ್ ನ ಉಪವಿಭಾಗವಾಗಿ ಉಪ ಕ್ಲಾಸ್ ಅನ್ನು ರಚಿಸಬಹುದು. ಆಬ್ಜೆಕ್ಟ್ ಗಳು ಕ್ಲಾಸ್ ನ ನಿದರ್ಶನಗಳಾಗಿವೆ.

ಹೆಚ್ಚು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ ಹಲವು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳು (ಉದಾಹರಣೆಗೆ C++, ಜಾವಾ, [೪] ಪೈಥಾನ್, ಇತ್ಯಾದಿ) ಬಹು-ಮಾದರಿಯಾಗಿದೆ ಮತ್ತು ಅವು ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅನ್ನು ಹೆಚ್ಚಿನ ಅಥವಾ ಕಡಿಮೆ ಮಟ್ಟದಲ್ಲಿ ಬೆಂಬಲಿಸುತ್ತವೆ. ಸಾಮಾನ್ಯವಾಗಿ ಇಂಪರೇಟಿವ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್, ಪ್ರೋಸಿಜರಲ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಸಂಯೋಜನೆಯೊಂದಿಗೆ ಮತ್ತು ಫಂಕ್ಷನಲ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ .

ಗಮನಾರ್ಹವಾದ ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಭಾಷೆಗಳಲ್ಲಿ ಅದಾ, ಆಕ್ಷನ್ ಸ್ಕ್ರಿಪ್ಟ್, ಸಿ ++, ಕಾಮನ್ ಲಿಸ್ಪ್, ಸಿ#, ಡಾರ್ಟ್, ಐಫೆಲ್, ಫೋರ್ಟ್ರಾನ್ 2003, ಹ್ಯಾಕ್ಸ್, ಜಾವಾ, [೪] ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್, ಕೋಟ್ಲಿನ್, ಲೋಗೋ, ಮ್ಯಾಟ್ಲಾಬ್, ಆಬ್ಜೆಕ್ಟಿವ್ -ಸಿ, ಪರ್ಜೆಕ್ಟ್ ಪಾಸ್ಕಲ್ ಪೈಥಾನ್, ಆರ್, ರಾಕು, ರೂಬಿ, ಸ್ಕಾಲಾ, ಸಿಮ್ಸ್ಕ್ರಿಪ್ಟ್, ಸಿಮುಲಾ, ಸ್ಮಾಲ್ಟಾಕ್, ಸ್ವಿಫ್ಟ್, ವಾಲಾ ಮತ್ತು ವಿಷುಯಲ್ ಬೇಸಿಕ್. ನೆಟ್ .

ಇತಿಹಾಸ

ಬದಲಾಯಿಸಿ

ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನ ಆಧುನಿಕ ಅರ್ಥದಲ್ಲಿ "ಆಬ್ಜೆಕ್ಟ್ ಗಳನ್ನು" ಆಹ್ವಾನಿಸುವ ಪರಿಭಾಷೆಯು 1950 ರ ದಶಕದ ಅಂತ್ಯದಲ್ಲಿ ಮತ್ತು 1960 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ MIT ಯಲ್ಲಿನ ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆ ಗುಂಪಿನಲ್ಲಿ ಮೊದಲ ಬಾರಿಗೆ ಕಾಣಿಸಿಕೊಂಡಿತು. ಗುರುತಿಸಲಾದ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ (ಗುಣಲಕ್ಷಣಗಳು) LISP ಪರಮಾಣುಗಳಿಗೆ "ಆಬ್ಜೆಕ್ಟ್" ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ. [೫] [೬] ಇನ್ನೊಂದು ಆರಂಭಿಕ MIT ಉದಾಹರಣೆಯೆಂದರೆ 1960-1961ರಲ್ಲಿ ಇವಾನ್ ಸದರ್‌ಲ್ಯಾಂಡ್ ರಚಿಸಿದ ಸ್ಕೆಚ್‌ಪ್ಯಾಡ್ ; 1963 ರ ತಾಂತ್ರಿಕ ವರದಿಯ ಗ್ಲಾಸರಿಯಲ್ಲಿ ಸ್ಕೆಚ್‌ಪ್ಯಾಡ್ ಕುರಿತು ಅವರ ಪ್ರಬಂಧವನ್ನು ಆಧರಿಸಿ, ಸದರ್ಲ್ಯಾಂಡ್ "ಆಬ್ಜೆಕ್ಟ್" ಮತ್ತು "ಇನ್ಸ್ ಟೆನ್ಸ್" ("ಮಾಸ್ಟರ್" ಅಥವಾ "ವ್ಯಾಖ್ಯಾನ" ದಿಂದ ಆವರಿಸಲ್ಪಟ್ಟ ಕ್ಲಾಸ್ ಪರಿಕಲ್ಪನೆಯೊಂದಿಗೆ) ಕಲ್ಪನೆಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದಾರೆ. ಆದರೂ ಚಿತ್ರಾತ್ಮಕ ಪರಸ್ಪರ ಕ್ರಿಯೆಗೆ ವಿಶೇಷವಾಗಿದೆ. [೭] ಅಲ್ಲದೆ, 1968 ರಲ್ಲಿ, MIT ALGOL ಆವೃತ್ತಿ, AED-0, ಡೇಟಾ ರಚನೆಗಳು ("plexes", ಆ ಉಪಭಾಷೆಯಲ್ಲಿ) ಮತ್ತು ಕಾರ್ಯವಿಧಾನಗಳ ನಡುವೆ ನೇರ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಿತು, ನಂತರ "ಸಂದೇಶಗಳು", "ವಿಧಾನಗಳು" ಮತ್ತು "ಸದಸ್ಯ ಕಾರ್ಯಗಳು" ಎಂದು ಕರೆಯಲ್ಪಟ್ಟವು. ". [೮] ಡೇಟಾ ಅಮೂರ್ತತೆ ಮತ್ತು ಮಾಡ್ಯುಲರ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಂತಹ ವಿಷಯಗಳು ಈ ಸಮಯದಲ್ಲಿ ಚರ್ಚೆಯ ಸಾಮಾನ್ಯ ಅಂಶಗಳಾಗಿವೆ.

ನಂತರದ MIT ಕೆಲಸಗಳಾದ AED, ಸಿಮುಲಾವನ್ನು 1961-1967 ವರ್ಷಗಳಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಯಿತು. ಸಿಮುಲಾ ಇಂದು ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನ ಅತ್ಯಗತ್ಯ ಭಾಗವಾಗಿರುವ ಪ್ರಮುಖ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಪರಿಚಯಿಸಿತು, ಉದಾಹರಣೆಗೆ ಕ್ಲಾಸ್ ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್, ಇನ್ ಹೆರಿಟೆನ್ಸ್ ಮತ್ತು ಡೈನಾಮಿಕ್ ಬೈಂಡಿಂಗ್ . [೯] ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಸಿಮುಲಾ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯನ್ನು ಮುಖ್ಯವಾಗಿ ಭೌತಿಕ ಮಾಡೆಲಿಂಗ್‌ನಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿರುವ ಸಂಶೋಧಕರು ಬಳಸಿದ್ದಾರೆ. ಉದಾಹರಣೆಗೆ ಹಡಗುಗಳ ಚಲನೆಯನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ಮತ್ತು ಸುಧಾರಿಸಲು ಮತ್ತು ಸರಕು ಬಂದರುಗಳ ಮೂಲಕ ಅವುಗಳ ವಿಷಯವನ್ನು ಸುಧಾರಿಸಲು ಮಾದರಿಗಳು. [೯]   MIT ಮತ್ತು ಸಿಮುಲಾ ಭಾಷೆಯಲ್ಲಿನ ಕೆಲಸದಿಂದ ಪ್ರಭಾವಿತರಾಗಿ, ನವೆಂಬರ್ 1966 ರಲ್ಲಿ ಅಲನ್ ಕೇ ಆಲೋಚನೆಗಳ ಮೇಲೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು. ಅದು ಅಂತಿಮವಾಗಿ ಸ್ಮಾಲ್‌ಟಾಕ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲಿ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿತು. ಕೇ [೧] ರಲ್ಲಿಯೇ ಸಂಭಾಷಣೆಯಲ್ಲಿ "ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್" ಎಂಬ ಪದವನ್ನು ಬಳಸಿದರು. ಕೆಲವೊಮ್ಮೆ "ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನ ಪಿತಾಮಹ" ಎಂದು ಕರೆಯಲಾಗಿದ್ದರೂ, [೧೦] ಅಲನ್ ಕೇ ಅವರು OO ದ ಕಲ್ಪನೆಯನ್ನು ಆಬ್ಜೆಕ್ಟ್ ನ ಹೆಚ್ಚು ಸಾಂಪ್ರದಾಯಿಕ ಅಮೂರ್ತ ಡೇಟಾ ಪ್ರಕಾರದ ಕಲ್ಪನೆಯಿಂದ ವಿಭಿನ್ನಗೊಳಿಸಿದ್ದಾರೆ ಮತ್ತು ಕಂಪ್ಯೂಟರ್ ಸೈನ್ಸ್ ಸ್ಥಾಪನೆಯು ಅವರ ಕಲ್ಪನೆಯನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿಲ್ಲ ಎಂದು ಸೂಚಿಸಿದ್ದಾರೆ. [೧] ಬಾರ್ಬರಾ ಲಿಸ್ಕೋವ್ ಸಹ-ಲೇಖಕರಾದ 1976 ರ MIT ಜ್ಞಾಪಕವು ಸಿಮುಲಾ 67, CLU, ಮತ್ತು ಆಲ್ಫರ್ಡ್ ಅನ್ನು ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಭಾಷೆಗಳು ಎಂದು ಪಟ್ಟಿ ಮಾಡಿದೆ, ಆದರೆ ಸ್ಮಾಲ್ಟಾಕ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುವುದಿಲ್ಲ.

೧೯೭೦ ರಲ್ಲಿ ಸ್ಮಾಲ್ ಟಾಕ್ ಪ್ರೊಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಮೊದಲ ವರ್ಷನ್ ಅನ್ನು ಝೆರಾಕ್ಸ್ ಪಿಎಆರ್ ಸಿ ಅಲ್ಲಿ ಅಲನ್ ಕೇ, ಡಾನ್ ಇಂಗಾಲ್ಸ್ ಮತ್ತು ಅಡೆಲೆ ಗೋಲ್ಡ್ ಬರ್ಗ್ ಅವರುಗಳಿಂದ ಅಭಿವೃದ್ದಿ ಪಡಿಸಲಾಯಿತು. ಸ್ಮಾಲ್ ಟಾಕ್-೭೨ ರಲ್ಲಿ ಮೊದಲು ಕಂಪೈಲ್ಡ್ ಭಾಷೆಯಾಗಿರದೆ ಇಂಟರ್ಪ್ರಿಟೆಡ್ ಭಾಷೆಯಾಗಿ ಡೈನಮಿಕಲಿ ಟೈಪ್ಡ್ ಪ್ರೊಗ್ರಾಮಿಂಗ್ ಪರಿಸರವನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಸ್ಮಾಲ್ ಟಾಕ್ ತನ್ನ ಅನ್ವಯಿಸುವಿಕೆಯನ್ನು ಭಾಷಾ ಮಟ್ಟದ ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೇಶನ್ ನಲ್ಲಿ ಮತ್ತು ಗ್ರಾಫಿಕ್ ಅಭಿವೃದ್ದಿಯ ಪರಿಸರಕ್ಕೆ ತೊಡಗಿಸಿಕೊಂಡಿದೆ. ತನ್ನ ಭಾಷಾ ಬೆಳವಣಿಗೆಯಲ್ಲಿ ಸ್ಮಾಲ್ ಟಾಕ್ ಹಲವು ಆವೃತ್ತಿಗಳನ್ನು [೧೧] ಒಳಪಡಿಸಿಕೊಂಡಿದೆ. ಸಿಮುಲಾ ೬೭ ಭಾಷೆಯ ಪ್ರಭಾವವನ್ನು ಸ್ಮಾಲ್ ಟಾಕ್ ಹೊಂದಿದ್ದರೂ, ಇದನ್ನು ಡೈನಮಿಕ್ ಆಗಿ ಕ್ಲಾಸ್ ಗಳ ರಚನೆ ಮತ್ತು ಮಾರ್ಪಡಿಸುವುದರಿಂದ, ಡೈನಮಿಕ್ ವ್ಯವಸ್ಥೆಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. [೧೨]

೧೯೭೦ ಮತ್ತು ೧೯೮೦ ರ ದಶಕದ ಕೊನೆ ಭಾಗದಲ್ಲಿ ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೆಡ್ ಪ್ರೊಗ್ರಾಮಿಂಗ್ ತನ್ನ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸಿಕೊಂಡಿತು. ೧೯೭೯ ರಲ್ಲಿ ಮಲ್ಟಿಪಲ್ ಇಂಹೆರಿಟೆನ್ಸ್ ಮತ್ತು ಮಿಕ್ಸಿನ್ಸ್ [೧೩] ಅನ್ನು ಪರಿಚಯಿಸಿದ ಫ್ಲೇವರ್ಸ್ ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೆಡ್ ಲಿಸ್ಪ್ ಭಾಷೆಯ ಅಭಿವೃದ್ಧಿ ಶುರುವಾಯಿತು. ೧೯೮೧ರಲ್ಲಿ ಗೋಲ್ಡ್ ಬರ್ಗ್ ಆಗಸ್ಟ್ ಸಂಚಿಕೆಯ ಬೈಟ್ ಮ್ಯಾಗಝೀನ್ ಅನ್ನು ಸಂಪಾದಿಸಿ ಸ್ಮಾಲ್ ಟಾಕ್ ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೆಡ್ ಅನ್ನು ಹೆಚ್ಚು ಜನರಿಗೆ ಪರಿಚಯಿಸಿದರು. ಲೂಪ್ಸ್ - ಇಂಟರ್ ಲಿಪ್ಸ್-ಡಿ ಯ ಆಬ್ಜೆಕ್ಟ್ ವ್ಯವಸ್ಥೆಯು ಸ್ಮಾಲ್ ಟಾಕ್ ಮತ್ತು ಫ್ಲೇವರ್ಸ್ ಇಂದ ಪ್ರಭಾವಿತಗೊಂಡಿದ್ದು, ಇದರ ಬಗ್ಗೆ ಲೇಖನವು ೧೯೮೨ ರಲ್ಲಿ ಪ್ರಕಟಗೊಂಡಿತು. ೧೯೮೬ರಲ್ಲಿ ಅಸೋಸಿಯೇಷನ್ ಫಾರ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಮಷೀನರಿ ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೆಡ್ ಪ್ರೊಗ್ರಾಮಿಂಗ್, ಸಿಸ್ಟಮ್ಸ್, ಲ್ಯಾಂಗ್ವೇಜಸ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ಸ್ (ಓಓಪಿಎಸ್ ಎಲ್ ಎ) ಎಂಬುದರ ಮೇಲೆ ಮೊದಲ ಸಮ್ಮೇಳನವನ್ನು ಆಯೋಜಿಸಿದರು, ೧,೦೦೦ ಜನರು ಪಾಲ್ಗೊಂಡಿದ್ದರು.

Among other developments was the Common Lisp Object System, which integrates functional programming and object-oriented programming and allows extension via a Meta-object protocol. In the 1980s, there were a few attempts to design processor architectures that included hardware support for objects in memory but these were not successful. Examples include the Intel iAPX 432 and the Linn Smart Rekursiv.

1980 ರ ದಶಕದ ಮಧ್ಯಭಾಗದಲ್ಲಿ ಆಬ್ಜೆಕ್ಟಿವ್-ಸಿ ಅನ್ನು ಬ್ರಾಡ್ ಕಾಕ್ಸ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದರು, ಅವರು ITT Inc. ನಲ್ಲಿ ಸ್ಮಾಲ್‌ಟಾಕ್ ಅನ್ನು ಬಳಸಿದರು. ತನ್ನ ಪಿಎಚ್‌ಡಿ ಪ್ರಬಂಧಕ್ಕಾಗಿ ಸಿಮುಲಾವನ್ನು ಬಳಸಿದ ಜಾರ್ನೆ ಸ್ಟ್ರಾಸ್ಟ್ರಪ್, ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ C++ ಅನ್ನು ರಚಿಸಿದರು. [೧೧] 1985 ರಲ್ಲಿ, ಬರ್ಟ್ರಾಂಡ್ ಮೆಯೆರ್ ಐಫೆಲ್ ಭಾಷೆಯ ಮೊದಲ ವಿನ್ಯಾಸವನ್ನು ಸಹ ನಿರ್ಮಿಸಿದರು. ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟವನ್ನು ಕೇಂದ್ರೀಕರಿಸಿದ, ಐಫೆಲ್ ಸಂಪೂರ್ಣವಾಗಿ ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಾಗಿದೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಸಾಫ್ಟ್‌ವೇರ್ ಜೀವನಚಕ್ರವನ್ನು ಬೆಂಬಲಿಸುವ ಸಂಕೇತವಾಗಿದೆ. ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಸಾಫ್ಟ್‌ವೇರ್ ಕನ್‌ಸ್ಟ್ರಕ್ಷನ್‌ನಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್ ಎಂಜಿನಿಯರಿಂಗ್ ಮತ್ತು ಕಂಪ್ಯೂಟರ್ ಸೈನ್ಸ್‌ನಿಂದ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಪ್ರಮುಖ ವಿಚಾರಗಳ ಆಧಾರದ ಮೇಲೆ ಐಫೆಲ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿ ವಿಧಾನವನ್ನು ಮೆಯೆರ್ ವಿವರಿಸಿದ್ದಾರೆ. ಐಫೆಲ್‌ನ ಗುಣಮಟ್ಟದ ಗಮನಕ್ಕೆ ಅತ್ಯಗತ್ಯ ಮೆಯೆರ್‌ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ, ಒಪ್ಪಂದದ ಮೂಲಕ ವಿನ್ಯಾಸ, ಇದು ವಿಧಾನ ಮತ್ತು ಭಾಷೆ ಎರಡರ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿದೆ.

1990 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ ಮತ್ತು ಮಧ್ಯದಲ್ಲಿ ಆಬ್ಜೆಕ್ಟ್-ಆಧಾರಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ತಂತ್ರಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳು ವ್ಯಾಪಕವಾಗಿ ಲಭ್ಯವಾದಾಗ ಪ್ರಬಲ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾದರಿಯಾಗಿ ಅಭಿವೃದ್ಧಿಗೊಂಡಿತು. ಇವುಗಳಲ್ಲಿ ವಿಷುಯಲ್ ಫಾಕ್ಸ್‌ಪ್ರೊ 3.0, [೧೪] [೧೫] [೧೬] ಸಿ++, [೧೭] ಮತ್ತು ಡೆಲ್ಫಿ ಸೇರಿವೆ[ಸಾಕ್ಷ್ಯಾಧಾರ ಬೇಕಾಗಿದೆ]</link> . ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ತಂತ್ರಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿರುವ ಗ್ರಾಫಿಕಲ್ ಯೂಸರ್ ಇಂಟರ್‌ಫೇಸ್‌ಗಳ ಹೆಚ್ಚುತ್ತಿರುವ ಜನಪ್ರಿಯತೆಯಿಂದ ಇದರ ಪ್ರಾಬಲ್ಯವನ್ನು ಇನ್ನಷ್ಟು ಹೆಚ್ಚಿಸಲಾಯಿತು. ಆಬ್ಜೆಕ್ಟಿವ್-C ನಲ್ಲಿ ಬರೆಯಲಾದ Mac OS X ನಲ್ಲಿನ ಕೊಕೊ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ನಿಕಟವಾಗಿ ಸಂಬಂಧಿಸಿರುವ ಡೈನಾಮಿಕ್ GUI ಲೈಬ್ರರಿ ಮತ್ತು OOP ಭಾಷೆಯ ಉದಾಹರಣೆಯನ್ನು ಕಾಣಬಹುದು. ಸ್ಮಾಲ್‌ಟಾಕ್ ಆಧಾರಿತ C ಗೆ ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್, ಡೈನಾಮಿಕ್ ಮೆಸೇಜಿಂಗ್ ವಿಸ್ತರಣೆಯಾಗಿದೆ. OOP ಟೂಲ್‌ಕಿಟ್‌ಗಳು ಈವೆಂಟ್-ಡ್ರಿವನ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನ ಜನಪ್ರಿಯತೆಯನ್ನು ಹೆಚ್ಚಿಸಿವೆ (ಆದಾಗ್ಯೂ ಈ ಪರಿಕಲ್ಪನೆಯು OOP ಗೆ ಸೀಮಿತವಾಗಿಲ್ಲ).

ETH ಜ್ಯೂರಿಚ್‌ನಲ್ಲಿ, ನಿಕ್ಲಾಸ್ ವಿರ್ತ್ ಮತ್ತು ಅವರ ಸಹೋದ್ಯೋಗಿಗಳು ಮಾಡ್ಯೂಲ್ ಗಡಿಗಳಲ್ಲಿ ಟೈಪ್ ಚೆಕ್ ಮಾಡುವ ಪರಿಕಲ್ಪನೆಯನ್ನು ತನಿಖೆ ಮಾಡಿದರು. ಮಾಡ್ಯುಲಾ-2 (1978) ಈ ಪರಿಕಲ್ಪನೆಯನ್ನು ಒಳಗೊಂಡಿತ್ತು, ಮತ್ತು ಅವುಗಳ ನಂತರದ ವಿನ್ಯಾಸ, ಒಬೆರಾನ್, ಆಬ್ಜೆಕ್ಟ್ ದೃಷ್ಟಿಕೋನ, ಕ್ಲಾಸ್ ಗಳು ಮತ್ತು ಅಂತಹ ಒಂದು ವಿಶಿಷ್ಟ ವಿಧಾನವನ್ನು ಒಳಗೊಂಡಿತ್ತು. ವಿರ್ತ್‌ನ ವಿನ್ಯಾಸದಲ್ಲಿ ಇಂಹೆರಿಟೆನ್ಸ್ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಏಕೆಂದರೆ ಅವನ ನಾಮಕರಣವು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಕಾಣುತ್ತದೆ: ಇದನ್ನು ಟೈಪ್ ವಿಸ್ತರಣೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ದೃಷ್ಟಿಕೋನವು ಬೇಸ್ ಕ್ಲಾಸ್ ನಿಂದ ಇಂಹೆರಿಟೆಡ್ ಕ್ಲಾಸ್ ವರೆಗೆ ಇರುತ್ತದೆ.

Ada, BASIC, Fortran, Pascal, ಮತ್ತು COBOL ಸೇರಿದಂತೆ ಈ ಹಿಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಹಲವು ಭಾಷೆಗಳಿಗೆ ಆಬ್ಜೆಕ್ಟ್-ಆಧಾರಿತ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಈ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಆರಂಭದಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸದ ಭಾಷೆಗಳಿಗೆ ಸೇರಿಸಿದ್ದರಿಂದ ಕೋಡ್‌ನ ಹೊಂದಾಣಿಕೆ ಮತ್ತು ನಿರ್ವಹಣೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಯಿತು.

ತೀರಾ ಇತ್ತೀಚೆಗೆ, ಪ್ರಾಥಮಿಕವಾಗಿ ಆಬ್ಜೆಕ್ಟ್ ಓರಿಯೆಂಟೆಡ್ ಆದ ಕೆಲವು ಭಾಷೆಗಳು ಹೊರಹೊಮ್ಮಿವೆ. ಆದರೆ ಅವು ಕಾರ್ಯವಿಧಾನದ ವಿಧಾನದೊಂದಿಗೆ ಸಹ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ. ಅಂತಹ ಎರಡು ಭಾಷೆಗಳು ಪೈಥಾನ್ ಮತ್ತು ರೂಬಿ . ಬಹುಶಃ ವಾಣಿಜ್ಯಿಕವಾಗಿ ಪ್ರಮುಖವಾದ ಇತ್ತೀಚಿನ ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಭಾಷೆಗಳು ಜಾವಾ, ಸನ್ ಮೈಕ್ರೋಸಿಸ್ಟಮ್ಸ್‌ನಿಂದ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಜೊತೆಗೆ C# ಮತ್ತು ವಿಷುಯಲ್ ಬೇಸಿಕ್. NET ( VB.NET), ಎರಡೂ ಮೈಕ್ರೋಸಾಫ್ಟ್‌ಗಾಗಿ . NET ವೇದಿಕೆಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಈ ಎರಡು ಚೌಕಟ್ಟುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಅದರ ರೀತಿಯಲ್ಲಿ, ಅನುಷ್ಠಾನದಿಂದ ಅಮೂರ್ತತೆಯನ್ನು ರಚಿಸುವ ಮೂಲಕ OOP ಅನ್ನು ಬಳಸುವ ಪ್ರಯೋಜನವನ್ನು ತೋರಿಸುತ್ತದೆ. VB.NET ಮತ್ತು C# ಕ್ರಾಸ್-ಲ್ಯಾಂಗ್ವೇಜ್ ಇಂಹೆರಿಟೆನ್ಸ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಒಂದು ಭಾಷೆಯಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಕ್ಲಾಸ್ ಗಳನ್ನು ಇತರ ಭಾಷೆಯಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಉಪಕ್ಲಾಸ್ ಗಳಿಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ವೈಶಿಷ್ಟ್ಯಗಳು

ಬದಲಾಯಿಸಿ

ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಆದರೆ ಎಲ್ಲಾ ಸಂಬಂಧಿತ ತಂತ್ರಗಳು ಮತ್ತು ರಚನೆಗಳು OOP ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ಹೇಳಿಕೊಳ್ಳುವ ಭಾಷೆಗಳಲ್ಲಿ ನೇರವಾಗಿ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಕೆಳಗೆ ಪಟ್ಟಿ ಮಾಡಲಾದ ವೈಶಿಷ್ಟ್ಯಗಳು ಬಲವಾಗಿ ಕ್ಲಾಸ್ ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ (ಅಥವಾ OOP ಬೆಂಬಲದೊಂದಿಗೆ ಬಹು-ಮಾದರಿ ) ಎಂದು ಪರಿಗಣಿಸಲಾದ ಭಾಷೆಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿದೆ, ಗಮನಾರ್ಹವಾದ ವಿನಾಯಿತಿಗಳನ್ನು ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ. [೧೮] [೧೯] ಕ್ರಿಸ್ಟೋಫರ್ ಜೆ. ಡೇಟ್ ಅವರು OOP ಯ ವಿಮರ್ಶಾತ್ಮಕ ಹೋಲಿಕೆ ಇತರ ತಂತ್ರಜ್ಞಾನಗಳಿಗೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ ಸಂಬಂಧಿತ, OOP ನ ಒಪ್ಪಿಗೆಯ ಮತ್ತು ಕಠಿಣವಾದ ವ್ಯಾಖ್ಯಾನದ ಕೊರತೆಯಿಂದಾಗಿ ಕಷ್ಟಕರವಾಗಿದೆ ಎಂದು ಹೇಳಿದ್ದಾರೆ. [೨೦]

OOP ಅಲ್ಲದ ಭಾಷೆಗಳೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ

ಬದಲಾಯಿಸಿ

ಮಾಡ್ಯುಲರ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಬೆಂಬಲವು ಸಾಂಸ್ಥಿಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಫೈಲ್‌ಗಳು ಮತ್ತು ಮಾಡ್ಯೂಲ್‌ಗಳಾಗಿ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಗುಂಪು ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಮಾಡ್ಯೂಲ್‌ಗಳು ನೇಮ್‌ಸ್ಪೇಸ್ ಆಗಿರುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದು ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿರುವ ಗುರುತಿಸುವಿಕೆಗಳು ಮತ್ತೊಂದು ಫೈಲ್ ಅಥವಾ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಅದೇ ಹೆಸರನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಪ್ರೊಸೀಜರ್ ಅಥವಾ ವೇರಿಯಬಲ್‌ನೊಂದಿಗೆ ಸಂಘರ್ಷ ವಿರುವುದಿಲ್ಲ.

ಆಬ್ಜೆಕ್ಟ್ ಗಳು

ಬದಲಾಯಿಸಿ

ಆಬ್ಜೆಕ್ಟ್ ಗಳು ಕೆಲವೊಮ್ಮೆ ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ ಕಂಡುಬರುವ ವಸ್ತುಗಳಿಗೆ ಸಂಬಂಧಿಸಿರುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಗ್ರಾಫಿಕ್ಸ್ ಪ್ರೋಗ್ರಾಂ "ಸರ್ಕಲ್", "ಸ್ಕ್ವೇರ್" ಮತ್ತು "ಮೆನು" ನಂತಹ ಆಬ್ಜೆಕ್ಟ್ ಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಆನ್‌ಲೈನ್ ಶಾಪಿಂಗ್ ವ್ಯವಸ್ಥೆಯು "ಶಾಪಿಂಗ್ ಕಾರ್ಟ್", "ಗ್ರಾಹಕ" ಮತ್ತು "ಉತ್ಪನ್ನ" ದಂತಹ ವಸ್ತುಗಳನ್ನು ಹೊಂದಿರಬಹುದು. [೨೧] ಕೆಲವೊಮ್ಮೆ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಹೆಚ್ಚು ಅಮೂರ್ತ ಘಟಕಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ ತೆರೆದ ಫೈಲ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುವ ವಸ್ತು, ಅಥವಾ US ವಾಡಿಕೆಯಿಂದ ಮೆಟ್ರಿಕ್‌ಗೆ ಮಾಪನಗಳನ್ನು ಭಾಷಾಂತರಿಸುವ ಸೇವೆಯನ್ನು ಒದಗಿಸುವ ವಸ್ತು. ಸಂಕೀರ್ಣ ಆಂತರಿಕ ರಚನೆಗಳನ್ನು ಹೊಂದಿರುವ ವೇರಿಯಬಲ್‌ಗಳಂತೆ ವಸ್ತುಗಳನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಪ್ರವೇಶಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅನೇಕ ಭಾಷೆಗಳಲ್ಲಿ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪಾಯಿಂಟರ್‌ಗಳಾಗಿರುತ್ತವೆ, ಹೀಪ್ ಅಥವಾ ಸ್ಟ್ಯಾಕ್‌ನ ಮೆಮೊರಿಯಲ್ಲಿ ಹೇಳಲಾದ ಆಬ್ಜೆಕ್ಟ್ ನ ಏಕೈಕ ನಿದರ್ಶನಕ್ಕೆ ನಿಜವಾದ ಉಲ್ಲೇಖಗಳಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಪ್ರೊಸೀಜರ್ ಗಳನ್ನು ಮೆಥೆಡ್ ಗಳು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ; ವೆರಿಯಬಲ್ ಗಳನ್ನು ಫೀಲ್ಡ್ ಗಳು, ಸದಸ್ಯರು, ಗುಣಲಕ್ಷಣಗಳು ಅಥವಾ ಗುಣಲಕ್ಷಣಗಳು ಎಂದೂ ಕರೆಯಲಾಗುತ್ತದೆ.

ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಇತರ ವಸ್ತುಗಳನ್ನು ಅವುಗಳ ನಿದರ್ಶನ ವೇರಿಯಬಲ್‌ಗಳಲ್ಲಿ ಒಳಗೊಂಡಿರಬಹುದು; ಇದನ್ನು ಆಬ್ಜೆಕ್ಟ್ ಸಂಯೋಜನೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಉದ್ಯೋಗಿ ಕ್ಲಾಸ್ ನಲ್ಲಿರುವ ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ನ "ಮೊದಲ_ಹೆಸರು" ಮತ್ತು "ಸ್ಥಾನ" ದಂತಹ ತನ್ನದೇ ಆದ ನಿದರ್ಶನ ವೇರಿಯಬಲ್‌ಗಳ ಜೊತೆಗೆ, ವಿಳಾಸ ಕ್ಲಾಸ್ ನಲ್ಲಿನ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು (ನೇರವಾಗಿ ಅಥವಾ ಪಾಯಿಂಟರ್ ಮೂಲಕ) ಹೊಂದಿರಬಹುದು. "ಹ್ಯಾಸ್-ಎ" ಸಂಬಂಧಗಳನ್ನು ಪ್ರತಿನಿಧಿಸಲು ಆಬ್ಜೆಕ್ಟ್ ಸಂಯೋಜನೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ: ಪ್ರತಿಯೊಬ್ಬ ಉದ್ಯೋಗಿಯು ವಿಳಾಸವನ್ನು ಹೊಂದಿರುತ್ತಾನೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಉದ್ಯೋಗಿ ಆಬ್ಜೆಕ್ಟ್ ವಿಳಾಸ ಆಬ್ಜೆಕ್ಟ್ ಸಂಗ್ರಹಿಸಲು ಒಂದು ಸ್ಥಳಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತದೆ (ನೇರವಾಗಿ ತನ್ನೊಳಗೆ ಹುದುಗಿದೆ ಅಥವಾ ಪಾಯಿಂಟರ್ ಮೂಲಕ ಉದ್ದೇಶಿಸಲಾದ ಪ್ರತ್ಯೇಕ ಸ್ಥಳದಲ್ಲಿ). ಡೇಟ್ ಮತ್ತು ಡಾರ್ವೆನ್ RDBMS ಅನ್ನು ಬೆಂಬಲಿಸಲು OOP ಅನ್ನು ಒಂದು ರೀತಿಯ ಕಸ್ಟಮೈಸ್ ಮಾಡಬಹುದಾದ ರೀತಿಯ ವ್ಯವಸ್ಥೆಯಾಗಿ ಬಳಸುವ ಸೈದ್ಧಾಂತಿಕ ಅಡಿಪಾಯವನ್ನು ಪ್ರಸ್ತಾಪಿಸಿದ್ದಾರೆ, ಆದರೆ ಇದು ಆಬ್ಜೆಕ್ಟ್ ಪಾಯಿಂಟರ್‌ಗಳನ್ನು ನಿಷೇಧಿಸುತ್ತದೆ. [೨೨]

OOP ಮಾದರಿಯು ಇತರ ಪ್ರಮುಖ ಅಂಶಗಳ (ಗಣನೆ/ಅಲ್ಗೋರಿದಮ್ ಗಳು) ವೆಚ್ಚದಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್ ವಿನ್ಯಾಸ ಮತ್ತು ಮಾಡೆಲಿಂಗ್‌ಗಾಗಿ ಆಬ್ಜೆಕ್ಟ್ ಗಳ ಬಳಕೆಯನ್ನು ಅತಿಯಾಗಿ ಒತ್ತಿಹೇಳಿದೆ ಎಂದು ಟೀಕಿಸಲಾಗಿದೆ. [೨೩] [೨೪] ಉದಾಹರಣೆಗೆ, OOP ಭಾಷೆಗಳು ಆಗಾಗ್ಗೆ ದತ್ತಾಂಶ ಸ್ಟ್ರಕ್ಚರ್ಸ್ ಗಳು ಮತ್ತು ಅಲ್ಗಾರಿದಮ್‌ಗಳಿಂದ ಪ್ರಕಾರಗಳಿಗೆ ಗಮನವನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ ಎಂದು ರಾಬ್ ಪೈಕ್ ಹೇಳಿದ್ದಾರೆ. [೨೫] ಫಂಕ್ಷನಲ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ಗೆ ವಿರುದ್ಧವಾಗಿ ಇದೆ ಎಂಬುದನ್ನು ಸ್ಟೀವ್ ಯೆಗೆ ಗಮನಿಸಿದರು: [೨೬]

Object Oriented Programming puts the nouns first and foremost. Why would you go to such lengths to put one part of speech on a pedestal? Why should one kind of concept take precedence over another? It's not as if OOP has suddenly made verbs less important in the way we actually think. It's a strangely skewed perspective.

ಕ್ಲೋಜುರ್‌ನ ಸೃಷ್ಟಿಕರ್ತ ರಿಚ್ ಹಿಕಿ, ಆಬ್ಜೆಕ್ಟ್ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನೈಜ ಪ್ರಪಂಚದ ಅತಿ ಸರಳವಾದ ಮಾದರಿಗಳು ಎಂದು ವಿವರಿಸಿದ್ದಾರೆ. ಸಮಯವನ್ನು ಸರಿಯಾಗಿ ರೂಪಿಸಲು OOP ಯ ಅಸಮರ್ಥತೆಯನ್ನು ಅವರು ಒತ್ತಿಹೇಳಿದರು, ಇದು ಸಾಫ್ಟ್‌ವೇರ್ ವ್ಯವಸ್ಥೆಗಳು ಹೆಚ್ಚಾಗಿ ಏಕಕಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದರಿಂದ ಹೆಚ್ಚು ಸಮಸ್ಯಾತ್ಮಕವಾಗುತ್ತಿದೆ. [೨೪]

ಅಲೆಕ್ಸಾಂಡರ್ ಸ್ಟೆಪನೋವ್ ವಸ್ತು ದೃಷ್ಟಿಕೋನವನ್ನು ಜೆನರಿಕ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ಗೆ ಪ್ರತಿಕೂಲವಾಗಿ ಹೋಲಿಸುತ್ತಾರೆ: [೨೩]

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all.

ಇಂಹೆರಿಟೆನ್ಸ್

ಬದಲಾಯಿಸಿ

OOP ಭಾಷೆಗಳು ವೈವಿಧ್ಯಮಯವಾಗಿವೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ OOP ಭಾಷೆಗಳು ಕ್ಲಾಸ್ ಗಳು ಅಥವಾ ಮೂಲಮಾದರಿಗಳ ರೂಪದಲ್ಲಿ ಕೋಡ್ ಮರುಬಳಕೆ ಮತ್ತು ವಿಸ್ತರಣೆಗಾಗಿ ಇಂಹೆರಿಟೆನ್ಸ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಇಂಹೆರಿಟೆನ್ಸ್ ಈ ರೂಪಗಳು ಗಮನಾರ್ಹವಾಗಿ ವಿಭಿನ್ನವಾಗಿವೆ, ಆದರೆ ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ನಿದರ್ಶನದ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಸಾದೃಶ್ಯದ ಪರಿಭಾಷೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಕ್ಲಾಸ್-ಆಧಾರಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿ, ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಶೈಲಿ, ಪ್ರತಿಯೊಂದು ವಸ್ತುವು ನಿರ್ದಿಷ್ಟ ವರ್ಗದ ನಿದರ್ಶನವಾಗಿರಬೇಕು . ಕ್ಲಾಸ್ ಡೇಟಾ ಸ್ವರೂಪ ಅಥವಾ ಪ್ರಕಾರವನ್ನು (ಸದಸ್ಯ ವೇರಿಯಬಲ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಪ್ರಕಾರಗಳನ್ನು ಒಳಗೊಂಡಂತೆ) ಮತ್ತು ಲಭ್ಯವಿರುವ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು (ಕ್ಲಾಸ್ ಮೆಥೆಡ್ ಗಳು ಅಥವಾ ಸದಸ್ಯ ಫಂಕ್ಷನ್ ಗಳು) ನಿರ್ದಿಷ್ಟ ಪ್ರಕಾರ ಅಥವಾ ಆಬ್ಜೆಕ್ಟ್ ನ ಕ್ಲಾಸ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಕನ್ಸ್ಟ್ರಕ್ಟರ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಕ್ಲಾಸ್ ನಲ್ಲಿ ವಿಶೇಷ ರೀತಿಯ ವಿಧಾನವನ್ನು ಕರೆಯುವ ಮೂಲಕ ಆಬ್ಜೆಕ್ಟ್ ಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ. ಕ್ಲಾಸ್ ಗಳು ಇತರ ಕ್ಲಾಸ್ ಗಳಿಂದ ಇಂಹೆರಿಟೆನ್ಸ್ ಆಗಿ ಪಡೆಯಬಹುದು, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು "ಒಂದು ರೀತಿಯ" ಸಂಬಂಧಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಕ್ರಮಾನುಗತದಲ್ಲಿ ಜೋಡಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲಾಸ್ ಉದ್ಯೋಗಿ ಕ್ಲಾಸ್ ವ್ಯಕ್ತಿಯಿಂದ ಇಂಹೆರಿಟೆನ್ಸ್ ಆಗಿ ಪಡೆಯಬಹುದು. ಪೋಷಕ ಕ್ಲಾಸ್ ಗೆ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಡೇಟಾ ಮತ್ತು ಮೆಥೆಡ್ ಗಳು ಮಕ್ಕಳ ಕ್ಲಾಸ್ ನಲ್ಲಿ ಅದೇ ಹೆಸರಿನೊಂದಿಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲಾಸ್ ನ ವ್ಯಕ್ತಿ "make_full_name()" ಮೆಥೆಡ್ ನೊಂದಿಗೆ "first_name" ಮತ್ತು " last_name" ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು. ಇವುಗಳು ಉದ್ಯೋಗಿ ಕ್ಲಾಸ್ ನಲ್ಲಿ ಲಭ್ಯವಿರುತ್ತವೆ, ಇದಕ್ಕೆ "ಸ್ಥಾನ" ಮತ್ತು "ಸಂಬಳ" ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು. ಕ್ಲಾಸ್ ಉದ್ಯೋಗಿಯ ಎಲ್ಲಾ ನಿದರ್ಶನಗಳು ಹೆಸರು, ಸ್ಥಾನ ಮತ್ತು ಸಂಬಳದಂತಹ ಒಂದೇ ರೀತಿಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗಿದೆ. ಪ್ರೊಸಿಜರ್ ಗಳು ಮತ್ತು ವೆರಿಯಬಲ್ ಗಳು ಕ್ಲಾಸ್ ಅಥವಾ ನಿದರ್ಶನಕ್ಕೆ ನಿರ್ದಿಷ್ಟವಾಗಿರಬಹುದು; ಇದು ಈ ಕೆಳಗಿನ ನಿಯಮಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ:

  • ಕ್ಲಾಸ್ ವೇರಿಯಬಲ್ ಗಳು - ಒಟ್ಟಾರೆಯಾಗಿ ಕ್ಲಾಸ್ ಗೆ ಸೇರಿವೆ; ಪ್ರತಿ ವೇರಿಯಬಲ್‌ನ ಒಂದು ನಕಲು ಮಾತ್ರ ಇರುತ್ತದೆ, ವರ್ಗದ ಎಲ್ಲಾ ಇನ್ಸ್ ಟೆನ್ಸ್ ಗಳಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ.
  • ಇನ್ಸ್ ಟೆನ್ಸ್ ವೇರಿಯಬಲ್‌ಗಳು ಅಥವಾ ಗುಣಲಕ್ಷಣಗಳು - ಪ್ರತ್ಯೇಕ ವಸ್ತುಗಳಿಗೆ ಸೇರಿದ ಡೇಟಾ; ಪ್ರತಿಯೊಂದು ವಸ್ತುವು ತನ್ನದೇ ಆದ ಪ್ರತಿಯನ್ನು ಹೊಂದಿದೆ
  • ಮೆಂಬರ್ ವೇರಿಯಬಲ್ ಗಳು - ನಿರ್ದಿಷ್ಟ ಕ್ಲಾಸ್ ನಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಕ್ಲಾಸ್ ಮತ್ತು ಇನ್ಸ್ ಟೆನ್ಸ್ ವೇರಿಯಬೆಲ್ ಎರಡನ್ನೂ ಸೂಚಿಸುತ್ತದೆ.
  • ಕ್ಲಾಸ್ ಮೆಥೆಡ್ ಗಳು - ಒಟ್ಟಾರೆಯಾಗಿ ಕ್ಲಾಸ್ ಗೆ ಸೇರಿದ್ದು ಮತ್ತು ಕಾರ್ಯವಿಧಾನದ ಕರೆಯಿಂದ ಕ್ಲಾಸ್ ವೇರಿಯಬಲ್‌ಗಳು ಮತ್ತು ಇನ್‌ಪುಟ್‌ಗಳಿಗೆ ಮಾತ್ರ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತದೆ
  • ಇನ್ಸ್ ಟೆನ್ಸ್ ಮೆಥೆಡ್ ಗಳು - ಪ್ರತ್ಯೇಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ ಸೇರಿವೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ವಸ್ತುವಿನ ಇನ್‌ಪುಟ್‌ಗಳು ಮತ್ತು ಕ್ಲಾಸ್ ವೇರಿಯಬಲ್‌ಗಳಿಗೆ ಇನ್ಸ್ ಟೆನ್ಸ್ ವೇರಿಯಬಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಭಾಷೆಯ ವ್ಯಾಖ್ಯಾನವನ್ನು ಅವಲಂಬಿಸಿ, ಸಬ್ ಕ್ಲಾಸ್ ಗಳು ಸೂಪರ್‌ಕ್ಲಾಸ್‌ಗಳಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ವಿಧಾನಗಳನ್ನು ಅತಿಕ್ರಮಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಅಥವಾ ಸಾಧ್ಯವಾಗದಿರಬಹುದು. ಕೆಲವು ಭಾಷೆಗಳಲ್ಲಿ ಬಹು ಇಂಹೆರಿಟೆನ್ಸ್ ಅನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ, ಆದರೂ ಇದು ಅತಿಕ್ರಮಣಗಳನ್ನು ಪರಿಹರಿಸುವುದನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸಬಹುದು. ಕೆಲವು ಭಾಷೆಗಳು ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಮಿಕ್ಸಿನ್‌ಗಳಂತಹ ಇತರ ಪರಿಕಲ್ಪನೆಗಳಿಗೆ ವಿಶೇಷ ಬೆಂಬಲವನ್ನು ಹೊಂದಿವೆ, ಆದಾಗ್ಯೂ, ಬಹು ಪರಂಪರೆಯನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ ಭಾಷೆಯಲ್ಲಿ, ಮಿಕ್ಸಿನ್ ಸರಳವಾಗಿ ಒಂದು ಕ್ಲಾಸ್ ಆಗಿದ್ದು ಅದು ಒಂದು ರೀತಿಯ ಸಂಬಂಧವನ್ನು ಪ್ರತಿನಿಧಿಸುವುದಿಲ್ಲ. ಒಂದೇ ವಿಧಾನಗಳನ್ನು ಅನೇಕ ಕ್ಲಾಸ್ ಗಳಿಗೆ ಸೇರಿಸಲು ಮಿಕ್ಸಿನ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲಾಸ್ ಯುನಿಕೋಡ್ ಕನ್ವರ್ಶನ್ ಮಿಕ್ಸಿನ್ unicode_to_ascii() ವಿಧಾನವನ್ನು ಕ್ಲಾಸ್ FileReader ಮತ್ತು ಕ್ಲಾಸ್ WebPageScraper ನಲ್ಲಿ ಸೇರಿಸಿದಾಗ ಒದಗಿಸಬಹುದು, ಇದು ಸಾಮಾನ್ಯ ಪೋಷಕರನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ಅಬ್ಸ್ ಟ್ರಾಕ್ಟ್ ಕ್ಲಾಸ್ ಗಳನ್ನು ಆಬ್ಜೆಕ್ಟ್‌ಗಳಾಗಿ ತತ್‌ಕ್ಷಣ ಮಾಡಲಾಗುವುದಿಲ್ಲ; ಅವು ಇತರ "ಕಾಂಕ್ರೀಟ್" ಕ್ಲಾಸ್ ಗಳಿಗೆ ಉತ್ತರಾಧಿಕಾರಕ್ಕಾಗಿ ಮಾತ್ರ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಜಾವಾದಲ್ಲಿ, ಕ್ಲಾಸ್ ಅನ್ನು ಸಬ್ ಕ್ಲಾಸ್ ನಿಂದ ತಡೆಯಲು final ಕೀವರ್ಡ್ ಅನ್ನು ಬಳಸಬಹುದು. [೨೭]

ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಪ್ರೊಟೋಟೈಪ್-ಆಧಾರಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ನಲ್ಲಿ, ವಸ್ತುಗಳು ಪ್ರಾಥಮಿಕ ಘಟಕಗಳಾಗಿವೆ. ಸಾಮಾನ್ಯವಾಗಿ, "ಕ್ಲಾಸ್" ಎಂಬ ಪರಿಕಲ್ಪನೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಬದಲಿಗೆ, ಒಂದು ವಸ್ತುವಿನ ಅಂದರೆ ಆಬ್ಜೆಕ್ಟ್ ನ ಮೂಲಮಾದರಿ ಅಥವಾ ಮೂಲವು ಆ ವಸ್ತುವು ಸಂಪರ್ಕ ಹೊಂದಿದ ಮತ್ತೊಂದು ವಸ್ತುವಾಗಿದೆ. ಸ್ವಯಂನಲ್ಲಿ, ಒಂದು ವಸ್ತುವು ಅನೇಕ ಅಥವಾ ಯಾವುದೇ ಪೋಷಕಗಳನ್ನು ಹೊಂದಿರಬಹುದು, [೨೮] ಆದರೆ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರೊಟೋಟೈಪ್-ಆಧಾರಿತ ಭಾಷೆಯಾದ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ, ಪ್ರತಿಯೊಂದು ವಸ್ತುವು ಒಂದು ಮೂಲಮಾದರಿಯ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರುತ್ತದೆ (ಮತ್ತು ಕೇವಲ ಒಂದು). ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಸ್ತುಗಳನ್ನು ಅವುಗಳ ಮೂಲಮಾದರಿಯಾಗಿ ಆಯ್ಕೆ ಮಾಡಿ ಹೊಸ ವಸ್ತುಗಳನ್ನು ರಚಿಸಬಹುದು. 'ಸೇಬು' ಮತ್ತು 'ಕಿತ್ತಳೆ' ಎರಡು ವಿಭಿನ್ನ ವಸ್ತುಗಳನ್ನು ಹಣ್ಣು ಎಂದು ಕರೆಯಬಹುದು, ಮತ್ತು ಸೇಬು ಮತ್ತು ತೆಂಗಿನಕಾಯಿ ಎರಡೂ ಹಣ್ಣುಗಳನ್ನು ಅವುಗಳ ಮೂಲಮಾದರಿಯಾಗಿ ಹೊಂದಿದ್ದರೆ. ಹಣ್ಣಿನ ವರ್ಗದ ಕಲ್ಪನೆಯು ಸ್ಪಷ್ಟವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಆದರೆ ಒಂದೇ ಮೂಲಮಾದರಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ವಸ್ತುಗಳ ಸಮಾನ ಕ್ಲಾಸ್ ಆಗಿ ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ತೃಪ್ತಿಪಡಿಸುವ ವಸ್ತುಗಳ ಗುಂಪಾಗಿ ರೂಪಿಸಬಹುದು. ಕ್ಲಾಸ್-ಆಧಾರಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ಗಿಂತ ಭಿನ್ನವಾಗಿ, ಪ್ರೊಟೋಟೈಪ್-ಆಧಾರಿತ ಭಾಷೆಗಳಲ್ಲಿ ಇತರ ವಸ್ತುಗಳೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳದ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ವಿಧಾನಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಧ್ಯವಿದೆ, ಉದಾಹರಣೆಗೆ, sugar_content ಗುಣಲಕ್ಷಣವನ್ನು ಸೇಬು ಭಾಷೆಯಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು ಆದರೆ ಕಿತ್ತಳೆಯಲ್ಲಿ ಆಗುವುದಿಲ್ಲ.

ಇಂಹೆರಿಟೆನ್ಸ್ ಮೇಲೆ ಸಂಯೋಜನೆ ಸಿದ್ಧಾಂತವು ಇಂಹೆರಿಟೆನ್ಸ್ ಬದಲಿಗೆ ಸಂಯೋಜನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಬಂಧಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದನ್ನು ಪ್ರತಿಪಾದಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲಾಸ್ ವ್ಯಕ್ತಿಯಿಂದ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವ ಬದಲು, ಕ್ಲಾಸ್ ಉದ್ಯೋಗಿ ಪ್ರತಿ ಉದ್ಯೋಗಿ ಆಬ್ಜೆಕ್ಟ್ ಗೆ ಆಂತರಿಕ ವ್ಯಕ್ತಿ ವಸ್ತುವನ್ನು ನೀಡಬಹುದು, ನಂತರ ಕ್ಲಾಸ್ ವ್ಯಕ್ತಿಯು ಅನೇಕ ಸಾರ್ವಜನಿಕ ಗುಣಲಕ್ಷಣಗಳು ಅಥವಾ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿದ್ದರೂ ಸಹ ಅದನ್ನು ಬಾಹ್ಯ ಕೋಡ್ನಿಂದ ಮರೆಮಾಡಲು ಅವಕಾಶವಿದೆ. ಗೋ. ನಂತಹ ಕೆಲವು ಭಾಷೆಗಳು ಆನುವಂಶಿಕತೆಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. [೨೯] ಇದು ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಆಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, [೩೦] ಮತ್ತು C + + ನ ಲೇಖಕ ಜಾರ್ನೆ ಸ್ಟ್ರೌಸ್ಟ್ರಪ್, ಆನುವಂಶಿಕತೆಯಿಲ್ಲದೆ OOP ಅನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿದೆ ಎಂದು ಹೇಳಿದ್ದಾರೆ. ಡೆಲಿಗೇಷನ್ ಎಂಬುದು ಮತ್ತೊಂದು ಭಾಷಾ ಲಕ್ಷಣವಾಗಿದ್ದು, ಇದನ್ನು ಆನುವಂಶಿಕತೆಗೆ ಪರ್ಯಾಯವಾಗಿ ಬಳಸಬಹುದು. [೩೧][೩೨]ರಾಬ್ ಪೈಕ್ ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅನ್ನು "ಕಂಪ್ಯೂಟಿಂಗ್ನ ರೋಮನ್ ಅಂಕಿಗಳು" ಎಂದು ಕರೆದಿದ್ದಾರೆ ಮತ್ತು ಜಾವಾ ಪ್ರಾಧ್ಯಾಪಕರ ಉದಾಹರಣೆಯನ್ನು ಉಲ್ಲೇಖಿಸಿದ್ದಾರೆ, ಅವರ ಸಮಸ್ಯೆಗೆ "ಭಾಷಾವೈಜ್ಞಾನಿಕ" ಪರಿಹಾರವೆಂದರೆ ಕೇವಲ ಒಂದು ನೋಟದ ಕೋಷ್ಟಕವನ್ನು ಬಳಸುವ ಬದಲು ಆರು ಹೊಸ ಕ್ಲಾಸ್ ಗಳನ್ನು ರಚಿಸುವುದು.

[೩೩]ಬಾಬ್ ಮಾರ್ಟಿನ್ ಅವರು ಸಾಫ್ಟ್ವೇರ್ ಆಗಿರುವುದರಿಂದ, ಸಂಬಂಧಿತ ಕ್ಲಾಸ್ ಗಳು ಅವರು ಪ್ರತಿನಿಧಿಸುವ ವಸ್ತುಗಳ ಸಂಬಂಧಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತಾರೆ.

ಕ್ರಿಯಾತ್ಮಕ ರವಾನೆ/ಸಂದೇಶ ರವಾನೆ

ಬದಲಾಯಿಸಿ

ವಿಧಾನದ ಕರೆಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಾರ್ಯವಿಧಾನದ ಕೋಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಆಬ್ಜೆಕ್ಟ್ ನ ಜವಾಬ್ದಾರಿಯಾಗಿದೆ. , ಸಾಮಾನ್ಯವಾಗಿ ಆಬ್ಜೆಕ್ಟ್ ಗೆ ಸಂಬಂಧಿಸಿದ ಕೋಷ್ಟಕದಲ್ಲಿ ರನ್ ಟೈಮ್ನಲ್ಲಿ ವಿಧಾನವನ್ನು ನೋಡುವ ಮೂಲಕ ಇದನ್ನು ಮಾಡಬಹುದು, ಯಾವುದೇ ಬಾಹ್ಯ ಕೋಡ್ ಬಳಕೆ ಅಲ್ಲ. ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಡೈನಾಮಿಕ್ ಡಿಸ್ಪ್ಯಾಚ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಕರೆ ವ್ಯತ್ಯಾಸವು ಅದನ್ನು ಕರೆಯುವ ಆಬ್ಜೆಕ್ಟ್ ನ ಒಂದೇ ಪ್ರಕಾರಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ (ಅಂದರೆ, ವಿಧಾನದ ಆಯ್ಕೆಯಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದು ಇತರ ನಿಯತಾಂಕ ಆಬ್ಜೆಕ್ಟ್ ಒಳಗೊಂಡಿರುತ್ತದೆ). ಮೆಥೆಡ್ ಕಾಲ್ ಅನ್ನು ಮೆಸೇಜ್ ಪಾಸಿಂಗ್ ಎಂದೂ ಕರೆಯಲಾಗುತ್ತದೆ. ಇದನ್ನು ಸಂದೇಶವಾಗಿ ಪರಿಕಲ್ಪನೆ ಮಾಡಲಾಗಿದೆ (ವಿಧಾನದ ಹೆಸರು ಮತ್ತು ಅದರ ಇನ್ಪುಟ್ ನಿಯತಾಂಕಗಳನ್ನು ರವಾನೆಗಾಗಿ ಆಬ್ಜೆಕ್ಟ್ ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ.

ಒಂದು ನಿರ್ದಿಷ್ಟ ಆಬ್ಜೆಕ್ಟ್ ಅಥವಾ ಕ್ಲಾಸ್ ನಲ್ಲಿ ಒಂದು ಮೆಥೆಡ್ ಇಲ್ಲದಿದ್ದರೆ, ರವಾನೆಯನ್ನು ಅದರ ಮೂಲ ಆಬ್ಜೆಕ್ಟ್ ಅಥವಾ ಕ್ಲಾಸ್ ಗೆ ನಿಯೋಜಿಸಿದರೆ ಮತ್ತು ಹೀಗೆ, ಆನುವಂಶಿಕತೆಯ ಸರಪಳಿಯ ಮೇಲೆ ಹೋದರೆ ರವಾನೆಯು ಆನುವಂಶಿಕತೆಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ.

ದತ್ತಾಂಶ ಅಬ್ಸ್ ಟ್ರ್ಯಾಕ್ಷನ್ ಮತ್ತು ಎನ್ಕ್ಯಾಪ್ಸುಲೇಷನ್

ಬದಲಾಯಿಸಿ

ಉಲ್ಲೇಖಗಳು

ಬದಲಾಯಿಸಿ
  1. ↑ ೧.೦ ೧.೧ ೧.೨ "Dr. Alan Kay on the Meaning of "Object-Oriented Programming"". 2003. Retrieved 11 February 2010. ಉಲ್ಲೇಖ ದೋಷ: Invalid <ref> tag; name "alanKayOnOO" defined multiple times with different content
  2. ↑ Kindler, E.; Krivy, I. (2011). "Object-Oriented Simulation of systems with sophisticated control". International Journal of General Systems: 313–343. {{cite journal}}: Cite journal requires |journal= (help)
  3. ↑ Lewis, John; Loftus, William (2008). Java Software Solutions Foundations of Programming Design 6th ed. Pearson Education Inc. ISBN 978-0-321-53205-3., section 1.6 "Object-Oriented Programming"
  4. ↑ ೪.೦ ೪.೧ Bloch 2018, pp. xi–xii, Foreword.
  5. ↑ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, David Luckham; Maling, K.; Park, D.; Russell, S. (March 1969). "LISP I Programmers Manual" (PDF). Computation Center and Research Laboratory of Electronics. Artificial Intelligence Group, M.I.T. Computation Center and Research Laboratory: 88f. Archived from the original (PDF) on 17 July 2010. In the local M.I.T. patois, association lists [of atomic symbols] are also referred to as "property lists", and atomic symbols are sometimes called "objects".
  6. ↑ McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, swapnil d.; Levin, Michael I. (1962). LISP 1.5 Programmer's Manual. MIT Press. p. 105. ISBN 978-0-262-13011-0. Object — a synonym for atomic symbol
  7. ↑ Sutherland, I. E. (30 January 1963). "Sketchpad: A Man-Machine Graphical Communication System". Technical Report No. 296, Lincoln Laboratory, Massachusetts Institute of Technology via Defense Technical Information Center (stinet.dtic.mil). Archived from the original on 8 April 2013. Retrieved 17 July 2019.
  8. ↑ Ross, Doug. "The first software engineering language". LCS/AI Lab Timeline. MIT Computer Science and Artificial Intelligence Laboratory. Retrieved 13 May 2010.
  9. ↑ ೯.೦ ೯.೧ Holmevik, Jan Rune (1994). "Compiling Simula: A historical study of technological genesis" (PDF). IEEE Annals of the History of Computing. 16 (4): 25–37. doi:10.1109/85.329756. Archived from the original (PDF) on 30 August 2017. Retrieved 3 March 2018.
  10. ↑ Butcher, Paul (30 June 2014). Seven Concurrency Models in Seven Weeks: When Threads Unravel (in ಇಂಗ್ಲಿಷ್). Pragmatic Bookshelf. p. 204. ISBN 978-1-68050-466-8.
  11. ↑ ೧೧.೦ ೧೧.೧ Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. p. 329. Bibcode:2009tclp.book.....M. ISBN 978-3-540-92144-8.
  12. ↑ Kay, Alan. "The Early History of Smalltalk". Archived from the original on 10 July 2008. Retrieved 13 September 2007.
  13. ↑ . June 1986. pp. 1–8. {{cite conference}}: |access-date= requires |url= (help); Missing or empty |title= (help)
  14. ↑ 1995 (June) Visual FoxPro 3.0, FoxPro evolves from a procedural language to an object-oriented language. Visual FoxPro 3.0 introduces a database container, seamless client/server capabilities, support for ActiveX technologies, and OLE Automation and null support. Summary of Fox releases
  15. ↑ FoxPro History web site: Foxprohistory.org
  16. ↑ 1995 Reviewers Guide to Visual FoxPro 3.0: DFpug.de
  17. ↑ Khurana, Rohit (1 November 2009). Object Oriented Programming with C++, 1E. Vikas Publishing House Pvt Limited. ISBN 978-81-259-2532-3.
  18. ↑ Deborah J. Armstrong. The Quarks of Object-Oriented Development. A survey of nearly 40 years of computing literature identified several fundamental concepts found in the large majority of definitions of OOP, in descending order of popularity: Inheritance, Object, Class, Encapsulation, Method, Message Passing, Polymorphism, and Abstraction.
  19. ↑ Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. ISBN 978-0-262-16209-8., section 18.1 "What is Object-Oriented Programming?" Lists: Dynamic dispatch, encapsulation or multi-methods (multiple dispatch), subtype polymorphism, inheritance or delegation, open recursion ("this"/"self")
  20. ↑ C. J. Date, Introduction to Database Systems, 6th-ed., Page 650
  21. ↑ Booch, Grady (1986). Software Engineering with Ada. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8. Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.
  22. ↑ C. J. Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2nd Edition)
  23. ↑ ೨೩.೦ ೨೩.೧ Stepanov, Alexander. "STLport: An Interview with A. Stepanov". Retrieved 21 April 2010.
  24. ↑ ೨೪.೦ ೨೪.೧ Rich Hickey, JVM Languages Summit 2009 keynote, Are We There Yet? November 2009.
  25. ↑ Pike, Rob (25 June 2012). "Less is exponentially more". Retrieved 1 October 2016.
  26. ↑ "Stevey's Blog Rants: Execution in the Kingdom of Nouns". Retrieved 20 May 2020.
  27. ↑ Bloch 2018, p. 19, Chapter §2 Item 4 Enforce noninstantiability with a private constructor.
  28. ↑ Dony, C; Malenfant, J; Bardon, D (1999). "Classifying prototype-based programming languages" (PDF). Prototype-based programming: concepts, languages and applications. Singapore Berlin Heidelberg: Springer. ISBN 9789814021258.
  29. ↑ . 2015. {{cite conference}}: Missing or empty |title= (help)
  30. ↑ "Is Go an object-oriented language?". Retrieved April 13, 2019. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy.
  31. ↑ Pike, Rob (14 November 2012). "A few years ago I saw this page". Archived from the original on 14 August 2018. Retrieved 1 October 2016.
  32. ↑ "[9fans Re: Threads: Sewing badges of honor onto a Kernel"]. Rob Pike mailing list. 2 March 2004. http://groups.google.com/group/comp.os.plan9/msg/006fec195aeeff15. 
  33. ↑ "Uncle Bob SOLID principles". YouTube.
"https://kn.wikipedia.org/w/index.php?title=ಆಬ್ಜೆಕ್ಟ್_ಓರಿಯೆಂಟೆಡ್_ಪ್ರೊಗ್ರಾಮಿಂಗ್&oldid=1249404" ಇಂದ ಪಡೆಯಲ್ಪಟ್ಟಿದೆ