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

/>   method send(iterator: ProfileIterator, message: string) is
    while (iterator.hasMore())
      profile = iterator.getNext()
      System.sendEmail(profile.getEmail(), message)

// Головний клас програми конфігурує ітератори та колекції, як
// завгодно.
class Application is
  field network: SocialNetwork
  field spammer: SocialSpammer

  method config() is
    if working with Facebook
      this.network = new Facebook()
    if working with LinkedIn
      this.network = new LinkedIn()
    this.spammer = new SocialSpammer()

  method sendSpamToFriends(profile) is
    iterator = network.createFriendsIterator(profile.getId())
    spammer.send(iterator, "Very important message")

  method sendSpamToCoworkers(profile) is
    iterator = network.createCoworkersIterator(profile.getId())
    spammer.send(iterator, "Very important message") Засто­су­ва­ння

Якщо у вас є скла­дна стру­кту­ра даних, і ви хоче­те при­хо­ва­ти від кліє­нта дета­лі її реа­лі­за­ції (з пита­нь скла­дно­сті або безпеки).

Іте­ра­тор надає кліє­нто­ві лише кілька про­стих мето­дів пере­бо­ру еле­ме­нтів коле­кції. Це не тільки спро­щує доступ до коле­кції, але й захи­щає її від необе­ре­жних або зло­чи­нних дій.

Якщо вам потрі­бно мати кілька варіа­нтів обхо­ду однієї і тієї самої стру­кту­ри даних.

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

Якщо вам хоче­ться мати єди­ний інте­рфе­йс обхо­ду різних стру­ктур даних.

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

Кроки реа­лі­за­ції

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

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

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

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

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

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

Ви може­те обхо­ди­ти дере­во Компо­ну­ва­льни­ка, вико­ри­сто­вую­чи Іте­ра­тор.

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

Зні­мок можна вико­ри­сто­ву­ва­ти разом з Іте­ра­то­ром, щоб збе­ре­гти пото­чний стан обхо­ду стру­кту­ри даних та пове­рну­ти­ся до нього в майбу­тньо­му, якщо буде потрібно.

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

Також відомий як: Intermediary, Controller, Mediator

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

Про­бле­ма

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

Без­ла­дні зв’язки між еле­ме­нта­ми інте­рфе­йсу користувача.

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

Код еле­ме­нтів потрі­бно пра­ви­ти під час зміни кожно­го діалогу.

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