Қазіргі таңда объектіге бағытталған бағдарламалауға деген бір ерекше әуестік бар, бірақ мен білетін ең мықты бағдарламашылардың кейбірі бұған онша қызыға қоймайды.
Менің өз ойымша, объектіге бағытталған бағдарламалау — кейбір жағдайларда пайдалы әдіс, бірақ ол сіз жазатын әрбір бағдарламаның өн бойына еніп кетуі міндетті емес. Сіз жаңа типтерді анықтай алуыңыз керек, бірақ әрбір бағдарламаны жаңа типтердің анықтамасы ретінде өрнектеуге мәжбүр болмауыңыз тиіс.
Меніңше, адамдардың объектіге бағытталған бағдарламалауды ұнатуының бес себебі бар, және олардың үш жарымы — нашар себептер:
Егер сізде лексикалық тұйықталулары (closures) немесе макростары жоқ, статикалық типтелген тіл болса, объектіге бағытталған бағдарламалау қызықты көрінеді. Белгілі бір дәрежеде ол осы шектеулерді айналып өтудің жолын ұсынады. (Гринспеннің оныншы ережесін қараңыз.)
Объектіге бағытталған бағдарламалау ірі компанияларда танымал, өйткені ол олардың бағдарламалық жасақтама жазу тәсіліне сәйкес келеді. Үлкен компанияларда бағдарламалық жасақтаманы ортанқол бағдарламашылардан құралған үлкен (әрі жиі ауысатын) командалар жазады. Объектіге бағытталған бағдарламалау бұл бағдарламашыларға олардың ешқайсысы тым көп зиян келтіре алмайтындай тәртіп орнатады. Оның төлемі — нәтижесінде шыққан код хаттамаларға (protocols) толып, көлемі ұлғайып, қайталануларға толы болады. Бұл үлкен компаниялар үшін тым жоғары баға емес, өйткені олардың бағдарламалық жасақтамасы бәрібір көлемі тым үлкен және қайталануларға толы болатын еді.
Объектіге бағытталған бағдарламалау сырт көзге үлкен жұмыс болып көрінетін көптеген нәрсені тудырады. Бағдарламалар перфокарталар мен тұтас қағаз таспаларда (fanfold) басылатын заманда бір бетке небары бес-он жол код жазып, оның алдына тым егжей-тегжейлі пішімделген жиырма жол түсіндірме (comment) қалдыратын бағдарламашылардың бір түрі болған. Объектіге бағытталған бағдарламалау мұндай адамдар үшін нағыз есірткі сияқты: ол сізге осы барлық көмекші құрылымдарды тікелей бастапқы кодтың ішіне енгізуге мүмкіндік береді. Lisp хакері тізімге бір символды қосу арқылы шешетін нәрсе кластар мен әдістердің тұтас бір файлына айналады. Сондықтан бұл өзіңізді немесе басқа біреуді көп жұмыс істеп жатырмын деп сендіргіңіз келсе, тамаша құрал.
Егер тілдің өзі объектіге бағытталған бағдарлама болса, оны пайдаланушылар кеңейте алады. Бәлкім, солай да шығар. Немесе объектіге бағытталған бағдарламалаудың ішкі тұжырымдамаларын жеке-жеке (a la carte) ұсыну арқылы бұдан да жақсы нәтижеге қол жеткізуге болатын шығар. Мысалы, қайта жүктеу (overloading) кластармен тығыз байланысты емес. Көре жатармыз.
Объектіге бағытталған абстракциялар модельдеу (simulation) және CAD жүйелері сияқты белгілі бір нақты бағдарламалардың саласына өте дәл сәйкес келеді.
Жеке өзіме объектіге бағытталған абстракциялар ешқашан қажет болған емес. Common Lisp өте қуатты объектілік жүйеге ие, бірақ мен оны бірде-бір рет пайдаланған емеспін. Мен әлсіздеу тілдерде объектіге бағытталған әдістерді қажет ететін көптеген нәрселерді жасадым (мысалы, тұйықталуларға толы хэш-кестелер жасау), бірақ маған CLOS қолданудың еш қажеті болмады.
Мүмкін, мен жай ғана ақымақ шығармын, не болмаса қосымшалардың шектеулі бір бөлігімен ғана жұмыс істеген болармын. Тілді өзіңнің жеке бағдарламалау тәжірибеңе сүйеніп жобалауда қауіп бар. Бірақ жақсы идея деп есептелгендіктен ғана өзіңе ешқашан қажет болмаған нәрселерді оған тықпалау одан да қауіптірек көрінеді.