Программалау оқулық Алматы, 012 Қазақстан Республикасы Білім жəне ғылым министрлігінің «Оқулық»
жүктеу/скачать 3,66 Mb. Pdf көрінісі
|
аибм сплюс
- Бұл бет үшін навигация:
- 9-ТАРАУ Программалау бойынша ұсыныстар
| void demo(B* p){
if (typeid(*p) == typeid(C)) dynamic_cast } int main(){ C* c = new C; demo(c); return 0; } Тип туралы ақпаратты диагностикалық мақсаттарда да қолданған пайдалы: void print_type(some_obj *p){ cout << typeid(*p).name(); } typeid операциясы виртуалды функциялардың орнына жəне объектінің типін компиляция кезеңінде анықтауға болатын жағдайларда қолданылмауы тиіс. 259 9-ТАРАУ Программалау бойынша ұсыныстар Кітаптың осы бөлімінде С++ тілінің объектіге бағытталған мүмкіндіктері қарастырылған болатын, енді программаны жазу барысында туындайтын мəселелерге тоқталатын уақыт жетті, олардың қатарында: əртүрлі жағдайларда тілдің қандай құралдарын таңдаған дұрыс, программа тиімді əрі сүйемелдеуге жеңіл болу үшін қандай мəселелерге ерекше көңіл бөлу қажет жəне неден аулақ жүру керек. Əрқашанда бірмəнді ұсыныстар беру мүмкін емес – тек С++ тілінің жұмыс істеу механизмін түсіну арқылы оны сауатты түрде қолдануға болады. Кез келген программалық өнімді құру жобалау үрдісінен басталады, бұл оның барысында туындайтын мəселелердің бірі – программаның объектіге бағытталған болуының міндетті немесе міндетті емес екендігін анықтау. Объектіге бағытталған программалаудың қажеттілігі жоқ есептер үшін оны қолдану тек программаның көлемін арттырады жəне жазу күрделілігін жоғарылатады. Егер мəселенің қойылымын талдау барысында кластар иерархиясын қолданудың қажеттілігі жоқ екендігі анықталса, көбінесе құрылымдық тəсілді пайдаланып программалау жеткілікті болып табылады. Б. Страуструптың тұжырымы бойынша, «анықталған типтегі бір объектіден артық қажет болмайтын барлық жерлерде, модульдердің көмегімен мəліметтер жасырылатын программалау стилін қолдану жеткілікті». Екі тəсілді бір жобада арластырып қолданбаған жөн, себебі дайын өнімде əрі құрылымдық, əрі объектіге бағытталған программа құру принциптерінің кемшіліктері табылуы мүмкін. Программаларды жобалау технологиясына арналып көптеген əдебиеттер жазылған жəне осы мəселені қарастыру бұл кітаптың міндеттеріне кірмейді. Түбегейлі программалық жобаларды қолға алғысы келетіндер үшін алдымен классикаға айналған Ф. Брукстың [6], Г. Бучтың [7] жəне Б. Страуструптың [17] кітаптарымен танысу керек. Осыдан кейін ғана программаларды құрудың келесі кезеңінде – программалық кодты жазу үрдісінде көңіл аударылуы тиіс мəселелер қарастырылады. Класты, яғни жаңа мəліметтер типін құру барысында оның интерфейсін – класты қолданатын программалаушылар қол жеткізе алатын жұмыс істеу құралдарын – жақсылап ойластыру керек. Жақсы жобаланған кластың интерфейсі бір қарағаннан-ақ интуитивтік түрде түсінікті, қарама- қайшылықсыз жəне көрнекі болуы тиіс. Көбінесе оның құрамында тек əдістер қарастырылып, мəліметтер өрістері болмауы тиіс. Мəліметтер өрістері жа- сырын ( private ) түрде берілуі керек. Осы арқылы кейіннен кластың жүзеге асырылуын оның интерфейсіне өзгеріс енгізбестен түрлендіруге, сонымен 260 қатар класс өрістерінің қолжетімділігін қолданушыға ұсынылатын əдістер жиынтығының көмегімен реттеуге мүмкіндік туады. Кластың барлық жасырын өрістері үшін get/set типті əдістерді анықтамаған жөн – бұл айтарлықтай күрделі жолмен оларды пайдалануға жол ашып берумен пара-пар. Класс өрістері оның интерфейсінде əдістер көмегімен бейнеленген класс қасиеттерін жүзеге асыру үшін ғана енгізілетінін естен шығармаған дұрыс. Əрине, егер кластың қасиеті осылайша жүзеге асы- рылатын болса, онда қандай да бір өрістің мəнін əдістің көмегімен алуға не- месе орнатуға болады (осылайша, код өзгеріссіз қалады да, ал бірақ оның мағынасы мүлде басқаша болады. Класс интерфейсін қажеттіліксіз, «керек болып қалар жағдай» үшін кеңейту керек емес, өйткені əдістер санының артуы қолданушының класты түсінуінде қиындықтар тудырады 1 . Мінсіз жағдайда интерфейс толық болуы тиіс, яғни класқа қатысты кез келген саналы əрекеттерді орындауға мүмкіндік беруі тиіс жəне интерфейс минималды болуы керек, яғни оның құрамында қайталаулар болмай, əдістер мүмкіндіктерінің қиылысуы да кездеспеуі тиіс. Əдістер ретінде тек кластың қасиеттерін жүзеге асыратын əрекеттерді анықтаған жөн. Егер қандай да бір əрекетті кластың жасырын өрістерін пайдаланбай-ақ жүзеге асыруға болатын болса, оны əдіс ретінде сипаттаудың қажеттілігі жоқ; оны класпен ортақ атаулар кеңістігіне орналастырып, қарапайым функция ретінде сипаттаған дұрыс. Егер функция класс қасиеті болып табылмайтын əрекетті орындап, бірақ оның жасырын өрістерін пай- далануы қажет болса, онда оны достас функция ретінде жариялау керек. Де- генмен, жалпы жағдайда достас функцияларды жəне кластарды қолданбаған жөн, өйткені ОБП-дың негізгі идеясы инкапсуляцияланған кластар арасында байланыстарды ең төменгі деңгейде ұстау (минималдау) болып табылады. Программаның өнімділігін арттыру үшін барынша жиі шақырылатын əдістерді кіріктірілген ( жүктеу/скачать 3,66 Mb. Достарыңызбен бөлісу:
|