Защо обектно-ориентираното програмиране има такова ударно влияние върху програмистката общност?
Обектно-ориентираното програмиране е привлекателно на много нива. За менажерите то обещава по-евтини и управляеми проекти. За аналистите и проектантите процесът се опростява и става по-управляем. За програмистите елегантността е привлекателна, а също и повишената производителност, те могат да експериментират и да я увеличат още повече. Види се, всички печелят.
Ако има обратна страна това е цената на кривата на обучението. Мисленето в термините на обекти драматично се различава от процедурното мислене и проектирането на обекти е много по-голямо предизвикателство от процедурите, особено ако се цели да се правят повторно използваеми обекти. В минарото новакът в обектно-ориентираното програмиране беше изправен пред две плашещи алтернативи:
-
Да избере език като Smalltalk при което трябва да изучи много и големи библиотеки докато стане продуктивен.
-
Да избере C++ с фактически никакви библиотеки1 и да се бори с дълбочините на езика поради нуждата да пише свои собствени библиотеки.
Да се правят хубави обекти е наистина трудно – ако е въпросът, трудно е да се направи добре каквото и да е. Намерението е обаче няколко добри проектанта да произведат обектите, които други ще използват. Успешните ООП езици предлагат не само синтаксис и компилатор, но и програмна среда с добре разработени библиотеки. По този начин най-първата задача на повечето програмисти е да използуват тези обекти. Целта на тази глава е да покаже какво е това ООП и колко просто може да бъде.
Тази глава ще въведе много от идеите на Java и обектно-ориентираното програмиране, но да сте наясно, че още няма да можете да пишете завършени Java след четенето на тази глава. Всичките детайлни описания и примери ще се дават с течение на курса.
Абстракцията
Всички програмни езици доставят абстракция. Може да се спори дали сложността на проблемите, които може да се решават зависи от вида и качеството на абстракцията. Под "вид" лазбирам: от какво се абстрахираме в рамките на езика? Езикът асемблер е малка абстракция на лежащата отдолу машина. Много от последвалите т.н. "императивни" езици (като FORTRAN, BASIC и C) бяха абстракции на асемблера. Тези езици са голям напредък в сравнение с асемблерите, но и при тях все още се налага да се мисли в термините на машината, наместо на решавания проблем. Програмистът трябва да прокара съответствие между машинния модел" (в "пространството на решенията) и модела на фактически решавания проблем (в "проблемното пространство"). Усилието, необходимо за това, което е външно за решавания проблем, довежда до програми, които са скъпи за произвеждане и трудни за поддържане, а като страничен ефект се получава цяла индустрия на "програмните методи".
Алтернативата на моделирането е моделиране на решавания проблем. Ранните езици като LISP и APL избраха конкретни свои гледни точки към света (“всички проблеми са списъци” и “всички проблеми са алгоритмични”). PROLOG свежда всички проблеми до вериги от решения. Бяха създадени езици за програмиране на/с ограничения и за работа изключително със знаци. (Последните се доказаха като твърде ограничителни.) Всеки от тези езици е добър за решаване на конкретния вид проблеми, за който са създадени, но стават тромави при всеки опит да се надникне навън.
Обектно-ориентирания подход прави стъпка по-нататък с даването на възможност да се моделират отделни части от проблемното пространство. Това представяне е толкова общо, че не поставя никакви огрраничения върху вида на решавания проблем. Ние се отнасяме към нещата в проблемното пространство от пространството на решенията като към "обекти". (Разбира се, ще са нужни и обекти, които нямат аналози в проблемното пространство.) Идеята е програмата на може да се настройва към езика на проблема чрез въвеждане на нови типове обекти така, че като четете кода който представлява решението му, да четете думи, които описват проблема. Това е по-гъвкава и мощна абстракция от всички предишни. Така ООП позволява да се опише проблема в термините на проблема, а не на решението. Има обаче връзка и с компютъра. Всеки обект изглежда мъничко като отделен компютър; има състояние, има операции, които може да се поръчат да изпълни. Това обаче не изглежда лоша аналогия на обектите от реалния свят; те всички имат своя характеристика и поведение.
Alan Kay сумира петте основни характеристики на Smalltalk, първият успешен ООП език и един от тези, на които е основан Java. Тези характеристики представят подхода на ООП в чист вид:
-
Всичко е някакъв обект. Мислете си го като фантастична променлива - може да се запомнят данни, но също може и да се поръчват обработки на данните. Теоретично може да се вземе който и да е обект от концепцията на решението на проблема (кучета, постройки, услугии т.н.) и да се представи като обект в програмата.
-
Програмата се състои от обекти, които си казват един на друг какво искат да правят чрез съобщения. За да поръчате нещо на обект му изпращате "съобщение". По-конкретно, за съобщението може да се мисли като за извикване на конкретна функция от конкретен обект.
-
Всеки обект си има своя собствена памет попълвана от други обекти. Или, прави се нов вид обект като се пакетират съществуващите обекти. Така може да построите сложността на програмата скривайки я зад простотата на обектите.
-
Всеки обект има тип. Всеки обект е екземпляр на клас, където “клас” е синоним на “тип.” Най-отличаващата характеристика на даден клас е “какви съобщения може да му се пращат?”
-
Всички обекти от даден тип могат да приемат едни и същи съобщения. Фактически това е пресилено твърдение, както ще видите по-нататък. Понеже обектът от тип кръг е също и от тип форма, кръгът гарантирано приема съобщенията за форма. Това значи че като напишете код който говори на формите автоматично включвате всичко, което има форма. Тази заменяемост е една от най-мощните концепции на ООП.
Някои проектанти са решили, че ООП не решава проблемите и адвокатстват на комбинацията на няколко подхода в многопарадигмените програмни езици.2
Сподели с приятели: |