Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à GRASP as an architecture base [URK]
Similaire à GRASP as an architecture base [URK] (20)
GRASP as an architecture base [URK]
- 2. GRASP як база в архітектурі Мажукін Олег Lead Android Dev
- 3. ● Що таке GRASP? ● Навіщо про нього говорити? ● SOLID, GRASP та інші шаблони ● Приклади використання GRASP патернів ● Як почати бачити GRASP у будь-якій архітектурі ● Як можно використовувати GRASP при code review Про що буде ця доповідь
- 4. General Responsibility Assignment Software Patterns ● Information Expert ● Creator ● Low Coupling/High Cohesion ● Controller ● Polymorphism ● Pure Fabrication ● Indirection ● Protected Variations Що таке GRASP?
- 5. Абстрактне рішення типових задач в програмуванні ● має конкретну назву ● складається з контексту/проблеми/рішення ● систематизує вже відомі рішення ● описують відношення між класами та об'єктами ● не прив'язаний до реалізації Що таке шаблони/патерни?
- 6. Проблема Одні об'єкти ( Observers ) хочуть реагувати на зміни в інших. Observers не знають, коли саме відбуваються зміни Рішення Нехай про Subject нотифікує Observers щодо зміни стану Приклад шаблону
- 7. Навіщо говорити про GRASP?
- 8. То cкільки потрібно знати патернів?
- 9. Тільки один
- 10. ● Single Responsibility Principle - кожен робить свою справу ● Open/Close Principle - нова логіка не змінює існуючу ● Liskov Substitution Principle - прикладний поліморфізм ● Interface Segregation Principle - розділяй і володарюй ● Dependency Inversion Principle - абстракції між рівнями Принципи SOLID
- 12. Проблема Як забезпечити слабку залежність між компонентами, стійкість до змін та збільшити повторне використання? Рішення Розподілити обов'язки таким чином, щоб між ними був низький Coupling Приклади Indirection Low Coupling
- 13. Coupling (зв'язаність) – це міра залежності одного елемента від інших. Клас А залежить від В, якщо: ● А має локальну зміну об'єкту В ● А викликає методи об’єкту B ● A є прямим або непрямим підкласом B ● A це інтерфейс, а B реалізує цей інтерфейс Що таке Coupling
- 14. До чого призводить: ● Один клас важко читати без іншого ● Зміна одного класу викликає зміну в інших ● Клас важче повторно використовувати, оскільки для його використання потрібні всі його залежності High Coupling
- 15. Low Coupling - Приклад
- 16. Проблема Як організувати взаємодію класів без прямої залежності? Як підтримувати низьку зв’язність та потенціал повторного використання? Рішення Обов'язок по взаємодії повинен виконувати окремий об'єкт Приклади Pure Fabrication Indirection
- 17. Indirection/Low Coupling - Приклад
- 18. Indirection/Low Coupling - Приклад
- 19. Low Coupling - Приклад
- 20. Low Coupling - Приклад
- 21. Low Coupling - Приклад
- 22. Low Coupling - Приклад
- 23. Проблема Як зробити об’єкт сфокусованим та зрозумілими, а також підтримувати Low Coupling? Рішення Розподілити обов'язки таким чином, щоб у класі була висока зв’язність High Cohesion
- 24. Cohesion (зачеплення) – це міра фокусування об'єкта на своїх обов'язках. До чого призводить Low Cohesion: ● важко зрозуміти ● важко підтримувати ● важко використовувати повторно ● постійно піддається впливу змін High Cohesion - Що таке зв’язність
- 25. Low Cohesion - Приклад
- 28. А як це виглядає у реальному проекті?
- 29. Проблема Який загальний принцип розподілу відповідальності між класами? Рішення Призначити обов’язок класу, який має всю необхідну інформацію для виконання відповідальності Information Expert
- 30. Information Expert - Приклад
- 31. Задача Перевірити, чи має акаунт право на Push? Варіанти рішення ● Винести перевірку в окремий клас ● Написати функцію в Акаунті Information Expert - Приклад
- 32. Information Expert - Приклад
- 33. Information Expert - Приклад
- 34. Information Expert - Приклад
- 35. ● High Cohesion ● Low Coupling ● Підвищує повторне використання Information Expert - Переваги
- 36. Проблема Як можно забезпечити взаємодію класів без порушення Low Coupling/High Cohesion, коли Information Expert недостатньо Рішення Призначити обов’язок забезпечення взаємодії окремому класу, який не є частиною предметної області Приклад Repository, Interactor Pure Fabrication
- 37. Pure Fabrication та предметна область
- 38. Pure Fabrication - Приклад
- 39. Проблема Хто відповідальний за створення екземпляру класу А? Рішення Призначити обов’язок класу В, якщо він має достатньо інформації для створення класу А. Приклади Mapper, Factory Creator
- 40. B має достатньо інформації, якщо: ● B «містить» або агрегує A. ● В записує А. ● B близько використовує A. ● B має дані для ініціалізації A тобто B є експертом щодо створення A. Creator - Достатньо інформації?
- 43. Проблема Який перший об’єкт за межами рівня інтерфейсу користувача отримує та координує («контролює») роботу системи? Рішення Призначити обов’язок обробки класу, який знає, як їх обробляти, або делегувати іншим компонентам. Приклади Presenter, ViewModel, ReduxStore Controller
- 46. Проблема Як спроектувати систему, щоб зміни однієї її частини не впливали на інші? Рішення Знайти точки можливих змін та розподілити обов'язки таким чином, щоб забезпечити стійку роботу системи Protected Variations
- 47. ● Зміна ТЗ ● Редизайн ● Рефакторинг ● Зміна архітектури ● Зміна/нестабільне Api ● Новий функціонал або розвиток існуючого Protected Variations - Види варіацій
- 48. ● SOLID ● GRASP ● GOF Patterns ● Покриття тестами ● Модульна архітектура ● Абстракції та інтерфейси Protected Variations - Як забезпечити?
- 49. Protected Variations - Приклади
- 53. Проблема Як обробляти альтернативні варіанти поведінки на основі типу? Рішення Забезпечити нову поведінку через поліморфні функції класу Приклади Strategy, Abstract Method Polymorphism
- 55. ● Розкажіть своїй команді про ГРАСП ○ Можна розподілити принципи між командою та зробити доповіді ● Домовтеся його дотримуватися ● Пишіть коментарі, посилаючись на принципии ● Закріплюйте домовленості в документації GRASP у code review?
- 56. ● Low Coupling/High Cohesion - баланс залежностей ● Information Expert - хто знає, той виконує ● Pure Fabrication - дозволяє делегувати обов’язок ● Creator - створює той, хто знає ● Controller - обробляє дії юзера ● Indirection - делегує взаємодію між класами ● Protected Variations - захищає від змін ● Polymorphism - дозволяє легко масштабуватись Рев’ю GRASP
- 57. GRASP це SOLID? Single Responsibility Principle High Cohesion Information Expert Creator Controller Open/Close Principle Indirection Liskov Substitution Principle Polymorphism Interface Segregation Principle Low Coupling Dependency Inversion Principle Pure Fabrication Protected Variations
- 58. ● Applying UML and Patterns ● З чого почати патерни ○ Head First Design Patterns ○ https://refactoring.guru/ ● Якщо ви вже не новачок в патернах Design Patterns: Elements of Reusable Object-Oriented Software Ресурси
- 59. Час запитань
Notes de l'éditeur
- Всім привіт, мене звуть Олег, я вже 9-ий рік займаюсь розробкою додатків під Android. Мені дуже подобається аналізувати різні рішення проблем, які виникають в процесі написання коду. При цього я намагаюсь розглядати як їх окремі деталі так і рішення взагалому. В такий спосіб я краще розумію чому вони працюють і сьогодні спробую поділитися цим з вами.
- Отже про що буде ця доповідь та для кого вона буде корисна. Сьогодні я розповім вам про GRASP: що це таке, як його використовувати, чи потрібен GRASP коли є SOLID та чим взагалі шаблони GRASP відрізняються від інших патернів. Доповідь буде корисна всім хто хоче почати краще розуміти як та чому працює та чи інша архітектура і про що потрібно думати коли пишеш свою.
- Давайте почнемо з того що дамо визначення ГРАСП. На відміну від SOLID де кожна з літер описує один з принципів, абревіатура ГРАСП розшифровується як загальні патерни ( або шаблони ) розподілу обов’язків у програмному забезпеченні. До його складу входять 9 шаблонів, які ми розглянемо по ходу доповіді. Всі вони дуже тісно пов'язані між собою. Вони настільки пов'язані що один шаблон може слугувати прикладом іншого або доповнювати чк його розуміти. Та перш ніж починати їх розбирати давайте згадаємо що собою представляє шаблон.
- Що ж таке шаблон? Шаблони то є способи вирішення типових проблем при проектуванні тобто основна їх задача спростити життя програмісту та не писати власне рішення з 0. При цьому шаблони систематизують вже відомі підходи та принципи, а не містять чогось нового. Тобто шаблон є прикладом вирішення проблеми та абстрактно описує відношення між класами та об'єктами без конкретної реалізації. Найвідомішими є шаблони банди чотирьох. Давайте для приклади розглянемо один з них.
- До складу шаблону зазвичай входить контект, наприклад… так Проблема.. яку вони вирішують. Рішення.. Тут ще раз наголошую що шаблон не є готовим рішенням, а лише загальним описом. Тому він може мати декілька реалізацій та модифікацій.
- Що цікаво патерни GRASP з’явились набагато пізніше патернів банди чотирьох. То навіщо говорити про GRASP? Для мене шаблони ГРАСП стоять десь посередині між SOLID та шаблонами банди чотирьох. Вони систематизують загальні підходи, які ми можемо побачити в цих патернах та деталізують деякі з принципів SOLID. ГРАСП не представляє собою нічого нового, скоріш за все ви впізнаєте ці шаблони тому що вже ними користуєтесь. При цьому як і інші патерни ГРАСП дозволяє легко та швидко розуміти один одного, наприклад при обговорення нової архітектури чи код ревью. Тому дуже корисно не тільки самому знати про них, але й поділитись досвідом з іншими.
- Отже багато скзано про патерни. То скільки потрібно знати патернів щоб писати гарні додатки? А що робити якщо твоя задача не є типовою? Або ти не можеш знайти той самий патерн, який вирішував би саме твою проблему? Може питання риторичні, але для себе я знайшов відповідь.
- І відповідь - тільки один. згоден, звучить трохи фантастично, але так само як Нео в Матриці постійно задаючи питання йшов вперед так і ми програмісти як дослідники постійно стикаємось з великою кількістю різних рішень та архітектур і що дивовижно всі вони працюють. Тут можно згадати як в Android’і звявився патерн MVP, який наче вирішував всі проблеми, а потім до нас прийшла й Чиста Архітектура від Роберт К. Мартіна. При цьому іноді ми навіть порушуємо правила закладені в архітектурі, а вона продовжує працювати. Перш ніж піти далі давайте пригадаємо принципи SOLID’a
- Ці використовують для дизайну та розробки систем, які, зможуть тривалий час розвиватися, розширюватися і підтримуватися. Давайте швидко згадає що до них входить. Liskov - системи працюють як з базовим класмо так і з його нащадками Шаблони GRASP, які ми розглянемо далі часто будут пересікатись з SOLID, але вони їх доповнюють чи розширюють тим самим допомагаючи нам краще їх розуміти
- Почну з найважливішої на мою думку пари - Low Coupling (Каплін) та High Cohesion (Кохіжен) в перекладі ( Низька зв'язаність та Високе зачеплення ). В українській мові ці назви дуже схожу тому я буду використовувати назву в оригіналі. Слід зазначити що один шаблон не має сенсу без іншого. Давайте розглянемо їх поодинці, а потім подивимось чому вони так сильно зв’язані.
- Першим розглянемо Low Coupling. Як і інші шаблони він описує рішення деякої проблеми. Отже проблема яку він вирішує то … і решенням є … Прикладом є інший патерн Inderection з ГРАСП який ми невдовзі розглянемо. Я привів його як приклад щоб ще раз наголосити наскільки всі патерни тісно пов'язані. То що таке зв'язаність?
- Каплін – це міра того, наскільки один елемент пов’язаний з іншими. А саме наскільки він від них залежить. До елементів можуть належати класи, пакети та модулі або навіть інші додатки. Розглянемо види коплінгу … Елемент з Low Coupling не залежить від багатьох інших елементів.
- Для того щоб пояснити чому шаблон називається саме Low Coupling давайте розглянемо до чого призводить високий. Отже … Хоча в прикладах я викостовую класи, те саме можно сказати наприклад про gradle модулі чи окремі фічі в додадку. Чесно кажучи мені здається що приклади для шаблонів набагато простіші ніж їх опис тому давайте подивимось на приклад
- Давайте уявимо що ми використовуємо MVVM як нашу архітектуру. В MVVM є VM, яка є посередником між даними та ui. І ось у нас є екран який показує дані со стору. Стор то наше джерело даних і нам не важливо звідки вони йдуть. При цьому дані потрібно пропустити через фільтр, а потім замапити на елементи готові до показу. В цьому прикладі ми бачимо що ВМ має залежність від трьох класів. Це означає що зміни в цих класах призведуть до змін в ВМ. Якщо уявити що декілька розробників працюють над цим екраном, то це призведе до конфліктів. Та це не єдина проблема цього прикладу. Що якщо нам потрібно буде відобразити ці самі дані на іншому екрані тоді нам потрібно тянути всю цю залежність до іншої ВМ. Як це можна вирішити?
- На допомогу прийде інший патерн, який я вже приводив як приклад, Індерекшен. Він вирішує декілька проблем…
- Тобто як варіант можно використати це ввести проміжний класс - Interactor в якому інкапсульована вся логіка отримання даних. Це дозволяє повторного його використати на іншому екрані, але тепер в нього три залежності на ці класи, тому всі проблеми ми ще не вирішили. Що можно зробити далі?
- Можна винести роботу с фільтром в Стор. Тоді цю логіку фільтрування може використати будь хто навіть не використовуючи інтерактор. А у інтерактора зменшується кількість залежностей.
- Давайте систематизуємо що ми тільки що розглянули. Як на мене найкраще для цього використовувати візуальне відображення зв’язків між елементами у вашому додатку. Уявимо що в нас є 4 елементи. Які зв'язки можуть між ними бути?
- Наприклад ось такі. Що тут можно сказати. Дивно зелене коло працює як з синім так і красним елементом при тому що у синього уже є зв'язок з красним. Якщо згадати наш приклад з ВМ, то при зміні красного коло це вплине на 2 елементи. В такому вигляді це може здаватись не великою проблемою, але ми розуміємо що у реальних додатків таких кол набагато більше і такі залежності ускладнюють написання нового коду. А які залежності були б більш гнучкими?
- Наприклад ось такі. Коли в нас лінійна залежність тобо всі елементи мають дуже чіткі обов'язки. В такому випадку легче доповнювати чи змінювати цю логіку. або інший приклад
- Ось такі залежності. В цьому випадку теж наче все добре. Виникає питання який з цих підходів кращий? Для того щоб це зрозуміти давайте розглянемо наступний шаблон.
- Високе зачеплення дає відповідть на питання.
- Це дуже схоже на принцип Single Responsibility. Під Cohesion розуміють міру фокусу об'єкта на своїх обов'язків. Аналогічно до лоу коплін давайте подивимось до чого призводить невиконання цих принципів а саме
- Давайте розглянемо наступний приклад. Колір обєктів то їх обовязок тобто якщо вони однакового кольору то виконують спільну функцію. Можно уявити що зелений, то робота с БД, червоний работа з АПИ, рожевий робота с ui. Вже знаючи про приклади low coupling/high cohesion тут видно що порушується Cohesion тобто елементи системи не мають чітко вираженого обов'язку та роблять все підряд. Часто такий патерн називають God Object, та записують його до антипатернів, які не слід використовувати. Перш ніж показати варіант в якому не порушується low coupling/high cohesion давайте порівняємо ці два шаблони.
- Отже Cohesion ( Зачеплення ) то про міру фокуса одного елементу системи, наприклад, класу чи модулю. Важливо щоб його фокус був на одному обов'язку та всі методи домогали його реалізовувати. Тому ми й намагаємося підтримувати High Cohesion. В свою чергу Coupling то про залежність між елементами і звісно потрібно намагатись її мінімізувати щоб зміни одних елементів мали мінімальний вплин на інші. Отже маючи це на увазі давайте повернемося до нашого прикладу.
- Ідеальний варіант буде виглядати ось так. Коли окремі елементи сфокусовані та виконують одну функцію, а взаємодія між елементами обмежена. Звісно не обов'язково щоб різні елементи мають тільки одну залежність один на одного.
- А як це може виглядати у реальному проекті? Наприклад, модульна система, коли кожен модуль відповідає за окрему частину функціоналу тобто підтримує High Cohesion. При цьому щоб підтримати Low Coupling краще організовувати взаємодію між модулями через спеціальний елменент. Ми ще повернемося до цього підходу в одному з інших прикладів. На мою думку всі інші шаблони то є способи досягти балансу між Low Coupling та High Cohesion.
- Одним з таких патернів є IE. Він допомагає досягти High Cohesion. Проблему яку він вирішує … а рішенням є. Щоб краще його зрозуміти давайте розглянемо наступний приклад.
- Хай у нас є Акуант с ролью. У кожної ролі є набір дозволів.
- І ось задача … Який з них вірний?
- Почнемо з окремого класу. Таким чином ця логіку на фігурує в акаунті, її можно легко розширити, але клас має залежність на Акаунт, Ролі та Пермішени. Тобто якщо один з цих класів зміниться, наприклад формат пермішенів, то наш клас теж потребує змін. З ішного боку його можно повторно використовувати в різних частинах програми, але це не зовсім правда і згодом ми розглянемо чому.
- Розглянемо альтернативний варіант коли перевірка будет с Акаунті. В цьому випадку в нас на одну залежність менше. То що нам каже патерн IE? Призначити обов’язок класу, який має всю необхідну інформацію для виконання відповідальності. В цьому випадку чи маэ всю необхідну інформацію Акаунт? На перший погляд так, але що буде якщо не маючи аккаунту потрібно отримати перимішени для ролі?
- В такому випадку краще перенести логіку до класу Role. Він буде мати залежність на клас пермішен, але якщо пермішен зміниться, то це задіне тільки клас Role.
- То які переваги такого підходу розподілу обов'язків? По перше підтримка High Cohesion тобто замість того щоб виносити функціональність в окремий клас, клас сам її реалізує. Тим самим підтримуємо Low Coupling того що зменшується кількість залежностей. А також якщо логіку буде у експерта - це підвищує повторне використання. З прикладом рішення в окремому класі інші розробники можуть про нього не знати і почати дублювати логіку. Те саме можно сказати про акаунт тому що якщо комусь потрібні пермішена без акаунти він напишу свою реалізацію. Тобто цей патерн вирішує одразу декілька проблем.
- Іншим патерном направленим на підтримання балансу Low Coupling/High Cohesion є Pure Fabrication. Він каже про що коли в експерта недостатньо інформації для того щоб виконати обов'язок можно передати цю функціональність іншому класу.
- Давайте розглянема що так предмета область? В ООП ми всі працюємо з абстракціями і деякі з них можуть мати реальнє відображення в системі яку ми програмуємо. Наприклад якщо ми розроблюємо додаток для магазину, то там будет покупець, продавець, заказ, тощо. При цьому в більшості випадків нам потрібні елементи які не входять до цієї області. В прикладі який ми розглядали Акаунт та Ролі входять до предметної області.
- Для прикладу Pure Fabrication можемо роглянути патерн Repositry, який інкапсулює в собі логіку роботи с даними.
- Ще одна класична задача в розробці - створення нових екземплярів класу. Патерн Creator вирішує цю проблему наступним чином…
- Для того щоб зрозуміти як він працює давайте розберем що значить достатньо інформації
- Дуже важливо розуміти що цей принцип не про те що логіку створення нових класів потрібно виносити в окремий клас. Він якраз про те що якщо у класу достатньо інформації про створення іншого то він і повинен цим займатись. Наприклад в Android’і є клас Актівіти, який представляє собою окремий екран. При цьому ui компоненти цього екрану лежать у файлі Layout. Для того щоб з ними працювати використовують спеціальний Binder клас. В даному прикладі у Актівіти достатньо інформації щоб його створити.
- Коли створення об'єкта занадто важке тоді його потрібно виносити в окремий клас. Наприклад таким чином працює патерн с банди чотирьох Factory.
- Одна з класичних проблем при написанні додатків з ui є обробтка дій користувача. Патерн контрлер …
- Зараз дуже пошерені патерни коли обработка дій користувача відбувається в окремих класах. Таким чином підтримується принципи Low Coupling/High Cohesion.
- Єдине про що потрібно пам'ятати що коле такий контролер починаю самостійно все виконувати без делегатів він може ставати дуже великим та порушувати інші патерни. Тому потрібно пам'ятати про інші патерни, які ми вже розглядали.
- Ми вже розглянули патерни які допомагають підтримувати баланс Low Coupling/High Cohesion. Наступний патерн допомагає вирішити які частини в системі перш за все необхідно захистити від змін.
- Які види варіацій можно виділити? … Як бути готовим до таких змін? Говорити з командаю та замовником про те яку функціональність планують додавати.
- То як захистити себе від змін? Тут можно згадати взагалі все що ми вже розглядали. Важливим при цьому є те що ви не намагаєтесь захиститись від всіх можливих змін, а в першу чергу виділяєте компоненти які потрібно зробити максимально гнучкими.
- На мою думку максимально захищена система в якій є виділені модулі, кожен з яких реалізую свою частину функціоналу. Наприклад в мобільних додатках то можуть бути фічі - авторизація, головна сторінка, деталі. Вони повинні взаємодіяти між собою через інтерфейси, та отримувати залежності через Dependency Inversion, коли той модуль що їх використовує сам дає їм всі необхідні залежності.
- Перж ніж ідти далі давайте розглянемо як абстракції та інтерфейси впливають на Coupling. В цьому прикладі у нас є два класи, які взаємодіють напряму.
- Ми можемо додати абстракцію, тоді їх залежність один від одного знизиться.
- А якщо додамо інтерфейс, то знизимо її ще більше, але в такому випадку в нас також знижується Cohesion. Тобто інтерфейс то не єдиний варіант знизити залежність. Асбтракції роболять те саме, тому іноді достатньо зробити клас абстракцію і якщо немає необхідности в різних реалізаціях інтерфейс не додавати.
- Ось ми і прийшли до останнього патерну, який думаю всім знайомий.
- В якості прикладу приведу ієрархію ui компонентів в Android. Тут є базовий класс View, який вміє розміщати себе на заданій локацію та малювати себе на екрані. У нього є нащадки для зображень, тексту та контейнерів для інших елементів. Всі вони мають однаковий інтерфейс для відображення тому можно просто створювати свої елементи не змінюючи базову логіку рендеренгу.
- То як можна використовувати ГРАС у код ревью? Тут все просто
- Давайте резюмуємо всі патерни, які сьогодні розглянули.
- Чи можно вважати ГРАСП SOLID’ом? І так, і ні, у них схожа ціль - виділити принципи, які можна використовувати кожен день при написанні додатків. SOLID дає дуже загальні рекомендації, в той час як GRASP виділяю конкретні проблеми та дає загальні рекомендації по їх вирішенню. Якщо їх порівняти, то я б…