Який хороший приклад cross-cutting concern? Приклад медичного обліку на сторінці вікіпедії мені здається неповним.
Зокрема, з цього прикладу, чому реєстрація призводить до дублювання ( розсіювання ) коду ? (Крім простих дзвінків, таких як log("....")скрізь, що не здається великою справою).
Яка різниця між a core concernі a cross-cutting concern?
Моя кінцева мета - краще зрозуміти АОП.
Відповіді:
Перш ніж зрозуміти концерн з наскрізним розрізом , ми повинні розібратися в концерні .
Занепокоєння це термін , який відноситься до частини системи , розділеної на основі функціональності.
Побоювання бувають двох типів:
Цей малюнок являє собою типову програму, розбиту на модулі. Основна проблема кожного модуля - надання послуг для конкретного домену. Однак кожен з цих модулів також вимагає подібних додаткових функцій, таких як реєстрація безпеки та управління транзакціями. Прикладом перехресних проблем є "ведення журналів", яке часто використовується в розподілених додатках для сприяння налагодженню викликами методів відстеження. Припустимо, ми робимо ведення журналу як на початку, так і в кінці кожного функції функції. Це призведе до схрещування всіх класів, які мають принаймні одну функцію.
Я думаю, що найкращим прикладом наскрізної проблеми є трансакційна поведінка. Наприклад, необхідність розміщення блоків пробного лову з викликами фіксації та відкату у всіх Ваших методах обслуговування буде відштовхувальною. Анотування методів маркером, який AOP може використовувати для інкапсуляції їх бажаною трансакційною поведінкою, - це великий виграш.
Ще одним хорошим кандидатом як прикладом наскрізної проблеми є авторизація. Анотування методу обслуговування маркером, який вказує, хто може його викликати, і надання деяким порадам AOP вирішувати, дозволити виклик методу чи ні, може бути кращим для обробки цього коду методу обслуговування.
Реалізація ведення журналу за допомогою порад AOP може бути способом отримати більшу гнучкість, щоб ви могли змінити те, що потрапляє в систему, змінивши точку з'єднання. На практиці я не бачу таких проектів дуже часто. Зазвичай використання такої бібліотеки, як log4j, яка дозволяє вам фільтрувати за рівнем журналу та категорією, під час виконання, якщо вам потрібно, виходить досить добре.
Основна проблема - це причина існування програми, бізнес-логіка, яку додаток автоматизує. Якщо у вас є логістична програма, яка займається доставкою вантажних перевезень, з'ясування того, скільки вантажу ви можете упакувати на вантажівку, або який найкращий маршрут для вантажівки, щоб відмовитись від її доставки, може бути ключовою проблемою. Наскрізні проблеми, як правило, деталі щодо впровадження, які потрібно уникати від бізнес-логіки.
Окрім прийнятої відповіді, хочу зазначити ще один приклад наскрізного занепокоєння: усунення. Скажімо, я просто хочу викликати інші компоненти в моїй екосистемі локально, як ніби вони працюють. Можливо, в деяких випадках вони це навіть роблять. Але тепер я хочу запустити свої сервіси, розповсюджені в хмарі або кластері. Чому я повинен дбати про цей аспект як розробник додатків? Аспект може допомогти визначити, кому дзвонити і як, послідовно передавати передані дані, якщо це необхідно, та здійснювати віддалений дзвінок. Якщо все працює в процесі, аспект просто переадресує місцевий дзвінок. На стороні виклику аспект десериалізує дані, здійснить локальний дзвінок та поверне результат.
Тепер дозвольте розповісти вам невелику історію про "тривіальні" речі, такі як вихід журналу: Лише кілька тижнів тому я відновив складну, але не занадто велику кодову базу (близько 250 К рядків коду) для клієнта. У кількох сотнях класів був використаний один вид каркасу лісозаготівлі, в іншому кілька сотень. Тоді було кілька тисяч рядківSystem.out.println(*)там, де дійсно повинен був бути вихідний журнал. Тож я закінчив виправити тисячі рядків коду, розкиданих по кодовій базі. На щастя, я міг би використати кілька хитромудрих хитрощів в IntelliJ IDEA (структурний пошук та заміна), щоб пришвидшити всю дію, але хлопчик, ти не вважаєш, що це було тривіально! Зрозуміло, що сильно залежати від контексту журнал налагодження завжди відбуватиметься в тілі методу, але багато важливих типів журналу, такі як виклики методу відстеження (навіть ієрархічно з чітко відрезаним результатом), ведення журналу як оброблених, так і необроблених винятків, аудит користувачів (реєстрація дзвінків до обмежені методи, засновані на ролях користувача) тощо можуть легко реалізовуватися в аспектах, не забруднюючи їх вихідним кодом. Щоденному розробнику додатків не потрібно думати про це або навіть бачити дзвінки реєстратора, розкидані по кодовій базі.
Я можу придумати подібні пояснення для інших наскрізних проблем. Зберігання коду чистим та вільним від розсіювання та заплутування IMO - це питання професіоналізму, не що інше. І останнє, але не менш важливе, він зберігає код читабельним, ремонтопридатним, реконструйованим. Амінь.
Спільні проблеми міжрізання - це сценарії, які завжди повинні бути присутніми незалежно від типу програми.
Наприклад, ведення журналів, безпека, профілювання продуктивності, локалізація, доступність, транзакція тощо. Незалежно від програмного забезпечення, яке ми будуємо, потрібен журнал (інакше як хтось буде налагоджувати або отримувати якусь релевантну інформацію з даних про продукти). Безпека (автентифікація / авторизація тощо) потрібна, коли в програму може входити лише справжній користувач із правильним набором привілеїв. Ми повинні знати, як працює ваша програма, тоді нам потрібно робити профілювання. У випадку, якщо додаток використовується міжнародними користувачами (зі своєю локалізованою мовою), тоді нам потрібно підтримувати те саме в додатку. Доступність - це випадки зручності використання інвалідів для використання нашого додатку.
Тепер незалежно від того, чи наша програма заснована на настільному ПК, веб-базі тощо, якщо її потрібно використовувати Кінцевим користувачам у всій географії у виробничому середовищі, тоді потрібні перерізи. До цього часу я нічого не говорив про те, що стосується програми тощо, але враховуючи перелік проблем, які слід вирішити, перш ніж випускати її кінцевим споживачам у виробничому середовищі. і це все з наскрізними проблемами (з якими потрібно обробляти всі програми / методи / класи, тобто на різних рівнях).