|
04.10.2017, 21:20 | #1 |
Участник
|
Цитата:
Предположим, у вас есть метод X класса Y у метода есть его публичный интерфейс:
И есть реализация (например он может изменить приватную переменную невидимую снаружи). Если расширения смогут отменять вызов какого угодно метода, то состояние объекта может быть испорчено. Так как ваше расширение не может учесть внутреннее состояние объекта будущих версий. Например в версии 1 вы написали расширение отменяющее вызов метода x целиком и как-то сымитировали его работу без того, что нам надо. И есть реализация (например он может изменить приватную переменную невидимую снаружи). Если расширения смогут отменять вызов какого угодно метода, то состояние объекта может быть испорчено. Так как ваше расширение не может учесть внутреннее состояние объекта будущих версий. Например в версии 1 вы написали расширение отменяющее вызов метода x целиком и как-то сымитировали его работу через публичный интерфейс. В версии 1 sp 1 внутрь добавили кеш, которое ваше расширение обновить не может (не только потому, что оно не может модифицировать приватные поля, но и потому, что оно написано для версии 1, про sp1 не знает) в результате остальные методы класса берут данные из кеша устаревшие. Собственно, если сделать подмену произвольного метода, то это и будет практически оверлееринг, но без удобного способа смотреть изменения. Последний раз редактировалось belugin; 04.10.2017 в 21:23. |
|
04.10.2017, 22:44 | #2 |
Banned
|
Цитата:
Ничего страшного в подмене нет. Это даст больше управляемости и надежности. А проверять конфликты можно и компилятором. В этой теме рассматривается паттерн обхода который в данном конкретном случае безопасен, но при отсутствии возможности подмены всего метода целиком, это превратится в рутинный подход который иначе как суицидным не назовешь. Kashperuk пишет что в Platform Update 11 что-то такое появится. Радостно наблюдать как пишется новый продукт. https://docs.microsoft.com/en-us/dyn...tform-releases |
|
05.10.2017, 08:55 | #3 |
Участник
|
*Теоретически* (то есть отвлекааясь от Аксапты данной нам в ощущениях) при создании расширения надо руководствоваться публичным контрактом метода включая побочные эффекты а не его исходным кодом (реализацией).
Контракт может быть описан как неформально (в XML документации) так и формально (например, набором тестов, Code Contracts). Цитата:
Ничего страшного в подмене нет. Это даст больше управляемости и надежности. А проверять конфликты можно и компилятором.
Цитата:
Ничего страшного в подмене нет. Это даст больше управляемости и надежности. А проверять конфликты можно и компилятором.
Последний раз редактировалось belugin; 05.10.2017 в 09:15. |
|
|
За это сообщение автора поблагодарили: Vadik (1), mazzy (2). |
05.10.2017, 20:42 | #4 |
Участник
|
вот это прямо золотые слова! это ж похоже на одного из трёх китов ООП!
__________________
Felix nihil admirari |
|
05.10.2017, 23:13 | #5 |
Banned
|
Цитата:
Чтение из файла например. А вот создание строки заказа уже по сути интерфейс к процессу. А там где процесс без исходного кода никак. Ничем. Да, хуже. От того что пытаются уйти от ошибок компиляции сам по себе оверлееринг никуда не исчезает. Его просто не видно. А со старым оверлеерингом - было видно. Ведь какая цель у нас программистов в большинстве случаев? Именно что логический оверлей какого-то процесса, просто потому что это в сути стоящих перед нами задач. Мало того что процессную систему прибили ООП так теперь еще и запретили менять процессы. Без возможности оверлееринга/подмены мы не можем вносить изменения в процесс, мы можем только подключать свои собственные независимые процессы. Это может быть нормально само по себе, но это совершенно недостаточно для (1 закона Кибернетики) тех требований которые предьявляет наш типичный клиент. Ладно бы не дурили голову себе и другим и закрыли систему намертво, это было бы и честно и логично. Но продолжать пропагандировать систему как платформу для разработки - это разрывает мозг. Вот EVGL хорошо иллюстрирует. Цитата:
Это все только слова и теоретические рассуждения. На практике все происходит с точностью до наоборот, и я могу это доказать на цифрах. При переходе с 7.1 на 7.2 наше приложение согласно отчету анализа обновления было затронуто 119 (прописью: сто девятнадцать) уничтоженными полями или таблицами, и это только data dictionary. Весь код, который это использовал - расширения, перекрытия, классы с бизнес-логикой - может идти лесом. Т.е. мастера по redesign / reengineering в Microsoft плевали на доработки и партнерские решения. Они ломали и будут ломать, с корнем удалять, менять внутреннюю логику. При этом самое худшее, что может случиться, это формально компилируемый код расширений, который просто перестал вызываться или работать из-за изменения порядка исполнения объектов.
Последний раз редактировалось ax_mct; 05.10.2017 в 23:17. |
|
|
За это сообщение автора поблагодарили: Link (1). |
06.10.2017, 08:36 | #6 |
Участник
|
Цитата:
Цитата:
А вот создание строки заказа уже по сути интерфейс к процессу. А там где процесс без исходного кода никак.
Цитата:
Ничем. Да, хуже. От того что пытаются уйти от ошибок компиляции сам по себе оверлееринг никуда не исчезает. Его просто не видно. А со старым оверлеерингом - было видно.
Цитата:
Ведь какая цель у нас программистов в большинстве случаев? Именно что логический оверлей какого-то процесса, просто потому что это в сути стоящих перед нами задач.
Цитата:
Без возможности оверлееринга/подмены мы не можем вносить изменения в процесс, мы можем только подключать свои собственные независимые процессы.
Цитата:
Вот EVGL хорошо иллюстрирует.
|
|
05.10.2017, 00:42 | #7 |
Banned
|
Цитата:
|
|
|
За это сообщение автора поблагодарили: Link (1), ax_mct (10), gl00mie (2). |
05.10.2017, 09:13 | #8 |
Участник
|
Цитата:
Сообщение от EVGL
Это все только слова и теоретические рассуждения. На практике все происходит с точностью до наоборот, и я могу это доказать на цифрах. При переходе с 7.1 на 7.2 наше приложение согласно отчету анализа обновления было затронуто 119 (прописью: сто девятнадцать) уничтоженными полями или таблицами, и это только data dictionary.
Практически сильно следят за обратной совместимостью при разработке хотфиксов и CU - то есть про обновления в рамках одной версии. При разработке следующей версии есть предупреждения которые можно игнорировать. Мне самому интересно, как можно совместить подход в котором:
Теоретически надо отделять те куски которые вендор может изменить, от тех которые он будет поддерживать и следить за этим. Для разделения у нас есть public protected private и internal (причем последнее заработало на всех уровнях только в последних PU). |
|
|
За это сообщение автора поблагодарили: Link (1). |
Теги |
chain of command, extensions |
|
|