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

Фасад можна зро­би­ти Оди­на­ком, оскі­льки зазви­чай потрі­бен тільки один об’єкт-фасад.

Фасад схо­жий на Замі­сник тим, що замі­нює скла­дну під­си­сте­му та може сам її іні­ціа­лі­зу­ва­ти. Але, на від­мі­ну від Фаса­ду, Замі­сник має такий самий інте­рфе­йс, що і його слу­жбо­вий об’єкт, завдя­ки чому їх можна взає­мо­за­мі­ня­ти.

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

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

Гра від­мі­нно пра­цю­ва­ла на вашо­му поту­жно­му комп’ютері, проте ваш друг пові­до­мив, що гра почи­нає гальму­ва­ти й вилі­тає через кілька хви­лин після запу­ску. Пере­ди­ви­вши­сь логи, ви вияви­ли, що гра вилі­тає через неста­чу опе­ра­ти­вної пам’яті. У вашо­го друга комп’ютер зна­чно менше «про­ка­ча­ний», тому про­бле­ма в нього й прояв­ляє­ться так швидко.

Дійсно, кожна части­нка у грі пре­д­став­ле­на вла­сним об’єктом, що має без­ліч даних. У певний моме­нт, коли побої­ще на екра­ні дося­гає кульмі­на­ції, опе­ра­ти­вна пам’ять комп’ютера вже не може вмі­сти­ти нові об’єкти части­нок, і про­гра­ма «вилі­тає».

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

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

Незмі­нні дані об’єкта при­йня­то нази­ва­ти «вну­трі­шнім ста­ном». Всі інші дані — це «зовні­шній стан».

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

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

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

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

Більш еле­га­нтним ріше­нням було б ство­ри­ти дода­тко­вий клас-конте­кст, який пов’язу­вав би зовні­шній стан з тим чи іншим легко­ва­го­ви­ком. Це дозво­ли­ть обі­йти­ся тільки одним полем-маси­вом у класі контейнера.

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

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

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

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

Зазви­чай цей метод додаю­ть до конте­йне­ра легко­ва­го­ви­ків або ство­рюю­ть окре­мий клас-фабри­ку. Його наві­ть можна зро­би­ти ста­ти­чним і роз­мі­сти­ти в класі легко­ва­го­ви­ків.

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

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