Обьектілі-бағдарланған программалаудың артықшылықтары мен кемшіліктері

Программалық жабдықтамаларды құрудың әр түрлі әдістемелерінен біз көптеген мәселелерді шешуге көмектесетінін күтеміз. Бірақ жобалаудың ең маңызды мәселелерінің бірі – күрделілік болып табылады. Программалық жүйе үлкен және күрделі болған сайын, оны нақты белгіленген, бірнеше бөліктерге бөлген маңызды болады. Ондай күрделіліктермен күресу үшін бөлшектерден абстракциялану қажет. Бұл мағынада класстар ыңғайлы құрал болып табылады.

• 
  Класстар жай құралдарды иеленетін пайдалы компоненттерден құрастыруды жүргізуге мүмкіндік береді, ал ол жүзеге асырылу бөліктерінен абстракциялануға мүмкіндік береді.
  
• 
  Берілгендер мен оларға жасалатын операциялар белгілі бір маңыздылықты құрайды және олар процедуралық программалау тәрізді бүкіл программа бойына таралмайды, тек бірге сипатталады. Код пен берілгендердің шектелуі программалық қамтамасыздандырудың көрнекілігі мен ыңғайлылығын жоғарылатады.
  
• 
  Инкапсуляция бірнеше орындаушылардың арасындағы есептерді қиғаштау мен жеке компоненттердің версияларын жаңартуды жеңілдететін модульділік қасиетін алып жүруге мүмкіндік береді.
  

Полиморфизм көбінесе келесі жағдайларда пайдалы болады:

• 
  Әркелкі берілгендер құрылымының өңделуі. Программалар обьектілер түрін айырмай жұмыс істей алады, бұл кодты елеулі түрде жеңілдетеді. Жаңа түрлері кез келген уақытта қосылуы мүмкін.
  
• 
  Орындалу барысында мінез-құлықтың өзгеруі. Орындалу кезеңінде қандай обьект қолданылып жатқанына байланысты кодты өзгертпей, алгоритмді жеңіл иемдетуге мүмкіндік беретін бір обьект басқа обьектімен алмастырылуы мүмкін.
  
• 
  Мұрагерлермен жұмыстың жүзеге асырылуы. Алгоритмдерді бір немесе одан да көп обьектілер түрлерімен жұмыс істей алатындай етіп жинақтауға болады.
  
• 
  «Каркастың» (framework) құрылуы. Қосымшадан тәуелсіз заттық саланың бөліктері әмбебап класстар немесе каркас (framework) түрінде жүзеге асырылуы мүмкін және кейін нақты қосымшалар үшін өзіндік бөліктердің қосылуының арқасында кеңейтіледі.
  

• 
  Басқа есептерді құруға берілетін уақыт қысқартылады.
  
• 
  Жаңа құрылған компоненттерге қарағанда, көп рет қолданылған компоненттердің қателері әдетте аз болады, себебі олар тексеруден бірнеше рет өтеді.
  
• 
  Әлдебір компонент бірнеше клиенттермен бір уақытта қолданылып жатқан кезде оның кодына енгізілген өзгертулер онымен бірге жұмыс істейтін көптеген программаларға оң әсер етеді.
  
• 
  Егер программа стандартты компоненттерге сүйенсе, оның құрылымы мен қолданбалы интерфейсі түсінуі мен қолдануды жеңілдететін аса жүйеленген болады.
  

• 
  Программалық жабдықтаманың күрделілігінің азаюы;
  
• 
  Программалық жабдықтаманың сенімділігінің жоғарылауы;
  
• 
  Программалық жабдықтаманың қалған компоненттерін өзгертпей, жеке компоненттерін түрлендіру мүмкіндігін қамтамасыз ету;
  
• 
  Программалық жабдықтаманың жеке компоненттерін қайта қолдану мүмкіндігін қамтамасыз ету.
  

Обьектілі-бағларланған программалау төрт нәрсені білуді қажет етеді:

1. 
   Класстар, мұрагерлену және динамикалық байланысу тәрізді базалық концепцияларды түсіну қажет. Модульдер түсінігі және мәліметтердің абстрактілі типтерін білетін программистер үшін, мұны түсінуге аз ғана күш қажет болады. Мәліметтердің инкапсуляциясын мүлде қолданбағандарға оны үйрену үшін көп уақыт қажет болады.
   
2. 
   Көп рет қолдану программистен үлкен класстар кітапханасымен танысуды қажет етеді. Ал бұл жаңа программалау тілін меңгеруден де қиын болуы мүмкін. Класстар кітапханасы өзіне жүздеген типтер мен мыңдаған операцияларды қосатын виртуалды тіл тәрізді болады. Мысалы, Smalltalk тілінде практикалық програмалауға көшу үшін, оның класстар кітапханасының қомақты бөлігін үйрену қажет.
   
3. 
   Класстарды жобалау – оларды қолданудан қарағанда, күрделі мәселе болып табылады. Класстарды жобалау, тілді жобалау тәрізді үлкен тәжірибені қажет етеді. Өз жіберген қателерінен үйренетін, итерациялық үрдіс.
   
4. 
   Класстарды байқап көру мүмкіндігі болмаса, оларды үйрену қиын болады. Аздаған тәжірибені алғаннан кейін жұмыс барысында обьектілі-бағдарланған программалауды сенімділікпен қолдануға болады.
   

Күрделі иерархиялық класстарда өрістер мен әдістер әдетте әр түрлі деңгейлерден мұрагерленеді. Қандай өрістер мен әдістер іс-жүзінде берілген классқа жататынын әрдайым анықтау мүмкін емес. Мұндай ақпаратты алу үшін класстар навигаторы тәрізді арнайы құралдар қажет. Егер нақты класс кеңейіп жатса, онда әр әдісті базалық классқа хабарламаны жіберер алдында қысқартады. Осындай әрекетпен операцияның жүзеге асырылуы бірнеше класстар бойынша орналастырылады және оның қалай жұмыс істейтінін түсіну үшін бізге бүкіл кодты мұқият қарауға тура келеді. Әдетте әдістер процедуралардан қысқа болады, себебі олар берілгендермен бір ғана операцияны жүзеге асырады, бірақ олар процедуралардан көп болады. Қысқа әдістерді түсіну жеңіл, бірақ олар хабарламаларды өңдеу үшін кодтың кейде көптеген кішкентай әдістерге бөлінетінімен ыңғайсыз болады.

Берілгендердің абстракциясын жөнсіз пайдалануға болмайды. Класс қойнауында логика мен берілгендер көбірек жасырылған сайын, оны кеңейту қиынға соғады. Мұндағы шығу нүктесі клиенттердің осы немесе басқа мәліметтерді білуі рұқсат етілмейтіні емес, клиенттерге класстармен жұмыс істеу үшін бұл мәліметтерді білудің қажеті жоқ.

Көбісі обьектілі-бағдарланған программалауды тиімсіз деп санайды. Біз орындалу кезеңіндегі тиімсіздік, жадыны үйлестірудегі тиімсіздік және артық әмбебаптылықпен байланысты тиімсіздік арасында нақты қырларды түсінуіміз керек.

1. Орындалу кезеңіндегі тиімсіздік. Smalltalk типті тілдерде хабарламалар қажетті әдісті таңдаудың арқасында және бір немесе бірнеше кестелердің ішінде іздеуді жүзеге асыру жолымен программаның орындалу барысында интерпретацияланады. Әрине, бұл баяу жүретін үрдіс. Тіпті, Smalltalk программасының оптимизацияланған ең жақсы әдістерін қолданғанның өзінде ол оптимизацияланған С программасынан 10 есе баяу болады.

Oberon-2, Object Pascal және C++ типті гибридті тілдерде қатынастарды жіберу тек көрсеткіш арқылы процедуралық айнымалыларды шақыруға әкеліп соғады. Кейбір машиналарда қатынаслар әдеттегі процедуралық шақыруларға қарағанда тек 10%-ке баяу орындалады. Программада қатынастар басқа операцияларға қарағанда сирек кездесетіндіктен, олардың ықпалының орындалу уақытына ешқандай әсері болмайды. Бірақ орындалу уақытына ықпал ететін басқа фактор бар, ол – берілгендердің инкапсуляциясы. Класстың әдістеріне тікелей енуді бермей, тек берілгендермен әр әрекетті әдістер арқылы орындау ұсынылады. Мұндай схема әрдайым мәліметке қол жеткізуде процедуралық шақыруды орындау қажеттілігіне алып келеді. Бірақ инкапсуляция тек қажетті жерде (яғни, артықшылық қалыптасқан жағдайларында) қолданылса, онда оның баяулылығы қолайлы болады.

2. Жадыны үйлестірудегі тиімсіздік. Орындалу кезеңіндегі динамикалық байланыстыру мен типті тексеру жұмыс барысында обьект типі туралы ақпаратты талап етеді. Мұндай ақпарат типтің дескрипторында сақталады және ол классқа жалғыз ерекшеленеді. Осылайша, обьектілі-бағдарланған программаларда қажетті қосымша жады обьект үшін бір көрсеткіште және класс үшін бір типтің дескрипторында беріледі.

3. Артық әмбебаптылық. Тиімсіздік тағы да программада артық мүмкіндіктердің жүзеге асырылғанын білдіруі мүмкін. Кітапханалық класстарда әдістер қажеттіліктен көп мөлшерде сақталады. Артық әдістер өшірілмегендіктен, олар пайдасыз жүкке айналады. Бұл программаның орындалу уақытына әсер етпейді, бірақ кодының мөлшеріне әсер етеді.

Мұның мүмкін болатын шешімдерінің бірі – аз ғана әдістері бар базалық класс құру, содан кейін функционалдылығын жоғарылатуға мүмкіндік беретін осы класстың әр түрлі кеңейтілімдерін жүзеге асыру. Басқа шешімі – үйлестірушіге артық әдістерді өшіру мүмкіндігін беру. Мұндай интеллектуалды үйлестірушілер әр түрлі тілдер мен операциялық жүйелер үшін бар.

Бірақ обьектілі-бағдарланған программалауды тиімсіз деп айтуға болмайды. Егер класстар нағыз қажетті жерде қолданылып жатса, онда тиімділіктің жадыны көп мөлшерде шығындау мен аз өнімділіктен жоғалуы болмашы нәрсе ғана. Сонымен қатар, программалық жабдықтаманың сенімділігі мен оны жазудың жылдамдығы өнімділігінен гөрі аса маңызды.