Читати книгу - "Занурення в патерни проектування, Олександр Швець"

Пате­рни прое­кту­ва­ння уні­ве­рса­льні. Тому всі при­кла­ди коду у цій книзі наве­де­но на псе­вдо­ко­ді, без прив’язки до конкре­тної мови про­гра­му­ва­ння.

Перед вивче­нням пате­рнів ви може­те осві­жи­ти пам’ять, про­йшо­вши­сь осно­вни­ми термі­на­ми об’єктно­го про­гра­му­ва­ння. Пара­ле­льно я роз­по­вім про UML-діа­гра­ми, яких у цій книзі при­ве­де­но вдо­ста­ль. Якщо ви все це вже знає­те, смі­ли­во при­сту­пайте до вивче­ння пате­рнів.

Об’єктно-оріє­нто­ва­не програ­му­ва­ння — це мето­до­ло­гія про­гра­му­ва­ння, в якій усі важли­ві речі пре­д­став­ле­ні об’єкта­ми, кожен з яких є екзе­мпля­ром того чи іншо­го класу, а класи утво­рюю­ть ієра­рхію успадкування.

Ви люби­те коше­нят? Спо­ді­ваю­сь, що люби­те, тому я спро­бую поясни­ти усі ці речі на при­кла­дах з котами.

Це UML-діа­гра­ма класу. У книзі буде бага­то таких діаграм.

Отже, у вас є кіт Пухна­стик. Він є об’єктом класу Кіт. Усі коти мають одна­ко­вий набір вла­сти­во­стей: ім’я, стать, вік, вагу, колір, улю­бле­ну їжу та інше. Це — поля класу.

Крім того, всі коти пово­дя­ться схо­жим чином: бігаю­ть, дихаю­ть, спля­ть, їдять і мурко­чу­ть. Все це — мето­ди класу. Уза­га­льне­но, поля і мето­ди іноді нази­ваю­ть чле­на­ми класу.

Зна­че­ння полів певно­го об’єкта зазви­чай нази­ваю­ть його ста­ном, а суку­пні­сть мето­дів — пове­ді­нкою.

Об’єкти — це екзе­мпля­ри класів.

Мурка, кішка вашої подру­ги, теж є екзе­мпля­ром класу Кіт. Вона має такі самі вла­сти­во­сті та пове­ді­нку, що й Пухна­стик, а від­рі­зняє­ться від нього лише зна­че­ння­ми цих вла­сти­во­стей — вона іншої статі, має інший колір, вагу тощо.

Отже, клас — це своє­рі­дне «кре­сле­ння», на під­ста­ві якого будую­ться об’єкти — екзе­мпля­ри цього класу.

Ідемо далі. У вашо­го сусі­да є соба­ка Жучка. Як відо­мо, і соба­ки, і коти мають бага­то спі­льно­го: ім’я, стать, вік, колір є не тільки в котів, але й у собак. Крім того, біга­ти, диха­ти, спати та їсти можу­ть не тільки коти. Вихо­ди­ть так, що ці вла­сти­во­сті та пове­ді­нка при­та­ма­нні усьо­му класу Тварини.

UML-діа­гра­ма ієра­рхії кла­сів. Усі класи на цій діа­гра­мі є части­ною ієра­рхії Тварин.

Такий батькі­вський клас при­йня­то нази­ва­ти супе­ркла­сом, а його наща­дків — під­кла­са­ми. Під­кла­си успа­дко­вую­ть вла­сти­во­сті й пове­ді­нку свого батька, тому в них місти­ться лише те, чого немає у супе­ркла­сі. Напри­клад, тільки коти можу­ть мурко­ті­ти, а соба­ки — гавкати.

Ми може­мо піти далі та виді­ли­ти ще більш зага­льний клас живих Організмів, який буде батькі­вським і для Тварин, і для Риб. Таку «піра­мі­ду» кла­сів зазви­чай нази­ваю­ть ієра­рхією. Клас Котів успа­дкує все, як з Тварин, так і з Організмів.

Класи на UML-діа­гра­мі можна спро­щу­ва­ти, якщо важли­ві­ше пока­за­ти зв’язки між ними.

Варто зга­да­ти, що під­кла­си можу­ть пере­ви­зна­ча­ти пове­ді­нку мето­дів, які їм діста­ли­ся від супе­ркла­сів. При цьому вони можу­ть, як повні­стю замі­ни­ти пове­ді­нку мето­ду, так і про­сто дода­ти щось до резуль­та­ту вико­на­ння батькі­всько­го методу.

ООП має чоти­ри голо­вні конце­пції, які від­рі­зняю­ть його від інших мето­до­ло­гій про­гра­му­ва­ння.

Коли ви пише­те про­гра­му, вико­ри­сто­вую­чи ООП, ви подає­те її части­ни через об’єкти реа­льно­го світу. Але об’єкти у про­гра­мі не повто­рюю­ть точно своїх реа­льних ана­ло­гів, та це й не завжди потрі­бно. Замі­сть цього об’єкти про­гра­ми всьо­го лише моде­люю­ть вла­сти­во­сті й пове­ді­нку реа­льних об’єктів, важли­вих у конкре­тно­му конте­кс­ті, а інші — ігнорують.

Так, напри­клад, клас Літак буде актуа­льним, як для про­гра­ми-тре­на­же­ра піло­тів, так і для про­гра­ми бро­ню­ва­ння авіа­кви­тків, але в першо­му випа­дку буду­ть важли­ви­ми дета­лі піло­ту­ва­ння літа­ка, а в дру­го­му — лише роз­та­шу­ва­ння та наявні­сть вільних місць усе­ре­ди­ні літака.

Різні моде­лі одно­го й того само­го реа­льно­го об’єкта.

Абстра­кція — це моде­ль деяко­го об’єкта або явища реа­льно­го світу, яка від­ки­дає незна­чні дета­лі, що не граю­ть істо­тної ролі в дано­му контексті.

Коли ви заво­ди­те авто­мо­бі­ль, доста­тньо пове­рну­ти ключ запа­лю­ва­ння або нати­сну­ти від­по­від­ну кно­пку. Вам не потрі­бно вру­чну з’єдну­ва­ти дроти під капо­том, пове­рта­ти колі­нча­стий вал та поршні, запу­скаю­чи такт дви­гу­на. Всі ці дета­лі при­хо­ва­ні під капо­том авто­мо­бі­ля. Вам досту­пний лише про­стий інте­рфе­йс: ключ запа­лю­ва­ння, кермо та педа­лі. Таким чином, ми отри­мує­мо визна­че­ння інте­рфе­йсу — публі­чної (public) части­ни об’єкта, що досту­пна іншим об’єктам.

Інка­псу­ля­ція — це зда­тні­сть об’єктів при­хо­ву­ва­ти части­ну свого стану й пове­ді­нки від інших об’єктів, надаю­чи зовні­шньо­му сві­то­ві тільки визна­че­ний інте­рфе­йс взає­мо­дії з собою.

Напри­клад, ви може­те інка­псу­лю­ва­ти щось все­ре­ди­ні класу, зро­би­вши його при­ва­тним (private) та при­хо­ва­вши доступ до цього поля чи мето­ду для об’єктів інших кла­сів. Трохи більш вільний, захи­ще­ний (protected) режим види­мо­сті зро­би­ть це поле чи метод досту­пним у підкласах.

На ідеях абстра­кції та інка­псу­ля­ції побу­до­ва­но меха­ні­зми інте­рфе­йсів і абстра­ктних кла­сів/мето­дів більшо­сті об’єктних мов про­гра­му­ва­ння.

Бага­тьох вво­ди­ть в оману те, що сло­вом