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

ж таки роз­бе­ре­мо­ся, що мали на увазі авто­ри патерна.

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

Тільки не плу­тайте ці термі­ни з інте­рфе­йса­ми або абстра­ктни­ми кла­са­ми вашої мови про­гра­му­ва­ння — це не одне і те ж саме.

Якщо гово­ри­ти про реа­льні про­гра­ми, то абстра­кцією може висту­па­ти гра­фі­чний інте­рфе­йс про­гра­ми (GUI), а реа­лі­за­цією — низько­рі­вне­вий код опе­ра­ці­йної систе­ми (API), до якого гра­фі­чний інте­рфе­йс зве­ртає­ться, реа­гую­чи на дії користувача.

Ви може­те роз­ви­ва­ти про­гра­му у двох різних напрямках:

мати кілька різних GUI (напри­клад, для зви­чайних кори­сту­ва­чів та адмі­ні­стра­то­рів). під­три­му­ва­ти бага­то видів API (напри­клад, пра­цю­ва­ти під Windows, Linux і macOS).

Така про­гра­ма може вигля­да­ти як один вели­кий клу­бок коду, в якому змі­ша­но умо­вні опе­ра­то­ри рівнів GUI та API.

Коли зміни беру­ть проект в «осаду», вам легше від­би­ва­ти­ся, якщо роз­ді­ли­ти моно­лі­тний код на частини.

Ви може­те спро­бу­ва­ти стру­кту­ру­ва­ти цей хаос, ство­ри­вши для кожної з варіа­цій інте­рфе­йсу-пла­тфо­рми свої під­кла­си. Але такий під­хід при­зве­де до зро­ста­ння кла­сів комбі­на­цій, і з кожною новою пла­тфо­рмою їх буде все більше й більше.

Ми може­мо вирі­ши­ти цю про­бле­му, засто­су­ва­вши Міст. Пате­рн про­по­нує роз­плу­та­ти цей код, роз­ді­ли­вши його на дві частини:

Абстра­кцію: ріве­нь гра­фі­чно­го інте­рфе­йсу програми. Реа­лі­за­цію: ріве­нь взає­мо­дії з опе­ра­ці­йною системою.

Один з варіа­нтів крос-пла­тфо­рмо­вої архітектури.

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

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

Стру­кту­ра

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

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

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

Конкре­тні реа­лі­за­ції містя­ть пла­тфо­рмо-зале­жний код.

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

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

Псе­вдо­код

У цьому при­кла­ді Міст діли­ть моно­лі­тний код при­ла­дів та пуль­тів на дві части­ни: при­ла­ди (висту­паю­ть реа­лі­за­цією) і пуль­ти керу­ва­ння ними (висту­паю­ть абстракцією).

При­клад поді­лу двох ієра­рхій кла­сів — при­ла­дів та пуль­тів керування.

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

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

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

// Клас пультів має посилання на пристрій, яким керує. Методи
// цього класу делегують роботу методам пов'язаного пристрою.
class Remote is
  protected field device: Device
  constructor Remote(device: Device) is
    this.device = device
  method togglePower() is
    if (device.isEnabled()) then
      device.disable()
    else
      device.enable()
  method volumeDown() is
    device.setVolume(device.getVolume() - 10)
  method volumeUp() is
    device.setVolume(device.getVolume() + 10)
  method channelDown() is
    device.setChannel(device.getChannel() - 1)
  method channelUp() is
    device.setChannel(device.getChannel() + 1)


// Ви можете розширювати клас пультів, не чіпаючи код пристроїв.
class AdvancedRemote extends Remote is
  method mute() is
    device.setVolume(0)


// Всі пристрої мають спільний інтерфейс, тому з ними може
// працювати будь-який пульт.
interface Device is
  method isEnabled()
  method enable()
  method disable()
  method getVolume()
  method setVolume(percent)
  method getChannel()
  method setChannel(channel)


// Разом з цим, кожен пристрій має особливу реалізацію.
class Tv implements Device is
  // ...

class Radio implements Device is
  // ...


// Десь у клієнтському програмному коді.
tv = new Tv()
remote = new Remote(tv)
remote.togglePower()

radio = new Radio()
remote = new AdvancedRemote(radio) Засто­су­ва­ння

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

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