D365: passing through public method by means of Pre- and Post-event handlers

[belugin]

Цитата:

Сообщение от ax_mct

Это если надо только воспользоваться процессом, например читаем из файла и создаем строку заказа. Разработка с типом "Интерфейс". Не вопрос.

Интерфейс может содержать колбеки и абстракции.

Цитата:

Но адаптирование той же AX под бизнес-процессы клиента это не реализация интерфейсных задач, а именно что изменение самих процессов. Разработка с типом "Изменение процесса".

Бывают изменения процессов которые предусмотрены разработчиками этих процессов.

Цитата:

Тупиковая стратегия использовать ООП применительно к бизнес-процессам ERP.
Поскольку деление на методы и обьекты делается в силу восприятия программиста, а не в силу обслуживания процесса.

Любая декомпозиция зависит от декомпозитора ОО тут вообще не причем. То же самое будет и с ФП и с чем угодно у чего есть модули или вообще какие-то куски с интерфейсом.

Цитата:

Как результат ничего кроме помех разделение на открытые-закрытые куски не принесет.

Надо спросить у Маззи его опыт оверллеринга форума с хуками

[mazzy]

Цитата:

Сообщение от belugin

Надо спросить у Маззи его опыт оверллеринга форума с хуками

Была у зайки избушка лубяная

Было у mazzy два купленных форума, с ежегодной подпиской, саппортом и всеми лицензионными пирогами.
один работал на движке vbulletin, второй - на Invision Power Board.

второй усложнял оверлеинг и в полный рост поощрял extensions. там была файловая структура и движок "собирал" нужный класс из каталогов.

В результате остался у mazzy один форум, на движке vbulletin.
хоть в нем и система хуков победнее, и специалист, глядя на мой код, только тяжко вздыхает и допиливает хуки...

но здесь худо-бедно живем вот уже 16 лет. да, конечно, с апгрейдом тяжеловато...

а на том extension-движке я репутацию у людей два раза терял и перезапускал из-за подключения разных модулей репутации... а потом в самом движке репутация появилась. так и не победил, рестартовал репутацию. За что извините меня, навижиноводы, дурака старого.

вот и сказочке конец, а кто слушал - молодец.

[mazzy]

Цитата:

Сообщение от belugin

Надо спросить у Маззи его опыт оверллеринга форума с хуками

На самом деле спрашивать надо конечно CRMщиков.
они с самого начала живут с закрытой системой.

Повторюсь, система extensions - не изобретение Microsoft и не нововведение для Аксапты.
Подобное давно уже существует в соседних продуктах MS.

Особый путь Аксапты - только переход от зрелой открытой системы со слоями к закрытой системе с extensions.
Такого я действительно не припомню.

[wojzeh]

Цитата:

Сообщение от skuull

Видимо правду говорят, что в Канаде сплошь лес да медведи
...
2.Доступ к protected полям класса.
...
6.Извращенцы могут скипнуть next.

я сам удивлён, как сдал экзамен по новой версии...

2. доступ к полям класса - есть примерчик?
6. скипнуть некст - и чо будет? по-моему, это самое интересное.

технически такая обёртка делается наследником класса с перекрытием метода и вызовом его супера, или есть какой-то другой подход?

[skuull]

Цитата:

Сообщение от wojzeh

6. скипнуть некст - и чо будет? по-моему, это самое интересное.

технически такая обёртка делается наследником класса с перекрытием метода и вызовом его супера, или есть какой-то другой подход?

Наследник без супера это хороший вариант, плохой в этой же теме на 2 странице D365: passing through public method by means of Pre- and Post-event handlers

Цитата:

Сообщение от wojzeh

2. доступ к полям класса - есть примерчик?

Ну есть у вас класс

class BusinessLogic1
{
 protected int a;
}

и вы можете делать так

[ExtensionOf(ClassStr(BusinessLogic1))]
final class BusinessLogic1_Extension
{
    public int getA()
    {
        return a;
    }
}

Очень полезно когда работаешь с классами\формами где переменные protected и доступ через Pre\Post к ним нет.

[wojzeh]

Цитата:

Сообщение от skuull

Наследник без супера это хороший вариант

это запрещённый приём (я так понял, тупо не скомпилируется), но это был вопрос не о решении частной проблемы, а о том, как это СОС технически реализован - так же в рамках ООП через перекрытие в наследниках? вот этот некст - это ж супер()?

Цитата:

Сообщение от skuull

Ну есть у вас класс...

ага, понял! спасибо

[ax_mct]

Цитата:

Сообщение от belugin

ОО тут вообще не причем. То же самое будет и с ФП и с чем угодно у чего есть модули или вообще какие-то куски с интерфейсом.

Причем-причем. Скажите как часто вы меняете в своих собственных классах или чужих private доступ на protected или public? Просто потому что изначальный дизайн всегда рано или поздно устаревает.

Какая такая защита реализации и инкапсуляция если если все наши усилия направлены на то что бы это обойти? Через рефлексию, через СоС, еще как-то как скажем в источнике данной темы.

Это какая-то просто увлекательная игра - ставить забор понадежней, а потом делать в нем дырки, и приставлять лестницы чтобы перелезть. О да, при этом через какой-то кусок забора лезть нельзя, а через какой-то можно. Все для безопасности охраняемого обьекта

[ax_mct]

Цитата:

Сообщение от wojzeh

это запрещённый приём (я так понял, тупо не скомпилируется), но это был вопрос не о решении частной проблемы, а о том, как это СОС технически реализован - так же в рамках ООП через перекрытие в наследниках? вот этот некст - это ж супер()?

Как пастух шотландских овец канадскому лесорубу: это горизонтально, а не вертикально.
Это не наследование, это расширение. Другая концепция. Происходит слияние сбоку, а не надстройка сверху.

[belugin]

Цитата:

Сообщение от ax_mct

Причем-причем. Скажите как часто вы меняете в своих собственных классах или чужих private доступ на protected или public? Просто потому что изначальный дизайн всегда рано или поздно устаревает.

Вы какие языки кроме ОО знаете? На чистом си можно вынести в заголовочный файл функцию или не выносить. Уровень доступа не является чем-то специфичным для ОО.

[belugin]

Цитата:

Сообщение от ax_mct

Это какая-то просто увлекательная игра - ставить забор понадежней, а потом делать в нем дырки, и приставлять лестницы чтобы перелезть. О да, при этом через какой-то кусок забора лезть нельзя, а через какой-то можно. Все для безопасности охраняемого обьекта

Это скорее система страховочных ограждений. "Если вы зайдете сюда, то может прилететь кирпич". Без хардллкинга - "Но если вы готовы надеть каску, то можете зайти" с хардлокингом "Но если вы предоставите заявку возможно мы для вас очистим еще безопасное место".

И опять-таки это не обязательно ОО - есть ОО без уровней доступа, есть модульные системы без ОО с уровнями доступа.

[ax_mct]

Цитата:

Сообщение от belugin

Вы какие языки кроме ОО знаете? На чистом си можно вынести в заголовочный файл функцию или не выносить. Уровень доступа не является чем-то специфичным для ОО.

Мне одинаково комфортно и со старым VB, и с классическим ANSI C, и с красивой Java, и с эффективным PHP и с безликим C#.

Я как тот лесоруб, мне не важно чем валить деревья. Но при этом из леса хочу выйти живым. Мне не очень нравится хаотичная и беспорядочная вырубка, когда я в каске между ними бегаю - "я в танке, я в танке...".

В настоящем танке те кто помечают сучки на деревья на "приватизированный сучок, защищённый или открытый". Просто невозможно их разметить так чтобы рано или поздно не напороться на это тем кто бегает в касках. Понятно что те кто в танке, те в танке.

[ax_mct]

Цитата:

Сообщение от belugin

Это скорее система страховочных ограждений.

http://kashperuk.blogspot.ru/2017/10...ibility_7.html

Цитата:

With Platform update 11 we have added a new attribute, which allows Microsoft (on request from multiple partnres), where it is justified, to decorate a particular protected or public method, allowing wrapper methods to not call next on it, replacing the logic of that method.

По обоснованным запросам Microsoft добавляет точки расширения (extension points) и с Platform update 11 (спасибо kashperuk за блог) по обоснованным запросам Microsoft будет добавлять атрибут (Replaceable) в конкретные методы с которым можно делать полную замену этого конкретного места.

Вроде бы неплохо и движение навстречу потребностям потребителям продукта. Но это "Скотный двор" Оруэлла. То есть постепенный переход с идей всеобщего равенства и построения утопии к диктатуре и тоталитаризму. При том что "Все партнеры равны. Но некоторые партнеры равны более, чем другие."

Я понимаю что с точки зрения Microsоft продукт принадлежит им и они позволяют им пользоваться.
Как сдача в аренду офисной площади или квартиры на условиях владельца. Любая дырка в стене требует разрешения собственника. Но не бывает таких жильцов которым бы это нравилось или устраивало. Всегда заканчивается переездом в собственный дом.

Что мешает сделать точки расширения и атрибут Replaceable во всех методах по умолчанию?
Страховочная система? Кого и от чего? Бред. Просто непонимание рынка и своего клиента.

[belugin]

Цитата:

Сообщение от ax_mct

Мне одинаково комфортно и со старым VB, и с классическим ANSI C, и с красивой Java, и с эффективным PHP и с безликим C#.

Тогда мне непонятно, почему вы считаете что разделение на интерфейс и реализацию, это ОО просто проанализируйте свой опыт

[belugin]

Цитата:

Сообщение от ax_mct

Что мешает сделать точки расширения и атрибут Replaceable во всех методах по умолчанию?

Давайте, вы сами проанализируйте что будет если сделать так, и чем именно это будет хуже оверлееринга.

Цитата:

Страховочная система? Кого и от чего? Бред. Просто непонимание рынка и своего клиента.

Зачем используют public и protected в Opensource и in-house продуктах?

[ax_mct]

Цитата:

Сообщение от belugin

Тогда мне непонятно, почему вы считаете что разделение на интерфейс и реализацию, это ОО просто проанализируйте свой опыт

Цитата:

Сообщение от belugin

Давайте, вы сами проанализируйте что будет если сделать так, и чем именно это будет хуже оверлееринга.
...
Зачем используют public и protected в Opensource и in-house продуктах?

Аксапта организована с использованием ОО, но реализация системы такова что разделение на интерфейс и реализацию просто лишено смысла. Делить живой и сложный организм на интерфейсы можно только его убив. Именно эту неуместность я имел в виду.

Аксапта не может быть protected, она может быть или public или private. Ну не дано третьего в кибернетике.

Абсолютно неинтересен доступ к отдельным кускам, либо полный доступ к телу либо нет. Полный доступ к телу означает что я не разобью голову об стену созданную ОО-нанитами на нано-уровне.

Самое плохое что для системы может случиться уже произошло, что такого может случиться если полностью развязать веревки - я не понимаю. Как-то же это тело жило до этого свободной жизнью плодясь и размножаясь.

Что случится то? Ошибки компиляции появятся? Такое впечатление что это основная беда, даже конфликт ISV на подмене метода с "Replaceable" проверяется в runtime как я понял.

[kashperuk]

Цитата:

Сообщение от ax_mct

http://kashperuk.blogspot.ru/2017/10...ibility_7.html

Что мешает сделать точки расширения и атрибут Replaceable во всех методах по умолчанию?
Страховочная система? Кого и от чего? Бред. Просто непонимание рынка и своего клиента.

Чем это тогда отличается от overlayering?
Так у МС есть хоть какой-то контроль над тем, где можно делать overlayering по сути

[ax_mct]

Цитата:

Сообщение от kashperuk

Чем это тогда отличается от overlayering?
Так у МС есть хоть какой-то контроль над тем, где можно делать overlayering по сути

Да, это будет худшая реализация смысла overlayering. Согласен. Но это не придает смысла следованию курсу по ограничению возможностей программирования.

Кто будет решать где можно делать overlayering, а где нет? Никто.
Есть архитектор который держит систему целостной и последовательной, отвечающей каким-то принципам проектирования? Нет.
Просто под достаточным давлением будут разрешать хаотично то там то здесь.
Это мы называем контролем?

[belugin]

Цитата:

Сообщение от ax_mct

Аксапта организована с использованием ОО, но реализация системы такова что разделение на интерфейс и реализацию просто лишено смысла.

Еще раз - при чем тут ОО. представьте что вам предоставили вместо ОО кода Plain C DLL без исходников, где вы можете только вызывать экспортированные функции, а поведение менять передавая указатели на функции. Или модули на паскале, кде в секцию interface вынесены только нуджные процедуры - будет та же ситуация безо всякого ОО.

Цитата:

Делить живой и сложный организм на интерфейсы можно только его убив.

Сложный организм так же обменивается сигналами и прочим. Иначе пересадка органов была бы невозможной.

Цитата:

Абсолютно неинтересен доступ к отдельным кускам, либо полный доступ к телу либо нет. Полный доступ к телу означает что я не разобью голову об стену созданную ОО-нанитами на нано-уровне.

Тут опять ОО совершенно не причем - причем это то, есть оверлееринг или нет.

[fed]

На протяжении всего времени существования системы, Damgaard/Navision/Microsoft поставляли прототип ERP-системы. Этот прототип на внедрениях допиливался партнерами и клиентами. Я просто рекомендую участникам belugin и kashperuk аккуратно перечитать свои сообщения, заменяя слова "библиотека" на "прототип библиотеки", "продукт" на "прототип продукта" и так далее. Очень поспособствует пониманию реальной ситуации на рынке.
Хотите использовать всякие передовые методы ОО, инкапсулирования и распределения обязаностей - прекрасно. Только помните что все эти методы были разработаны для продуктов, а не прототипов. Доделайте свой прототип до состояния продукта - вот тогда можно будет разговаривать про ОО, скрытие и инкапсуляцию.

[belugin]

Цитата:

Сообщение от fed

Я просто рекомендую участникам belugin и kashperuk аккуратно перечитать свои сообщения, заменяя слова "библиотека" на "прототип библиотеки", "продукт" на "прототип продукта" и так далее.

Если внимательно прочитать мои сообщения, то я нигде не выступаю за тотальный запрет оверлееринга. Возможно, у системы есть части, где он не очень нужен и где очень нужен. Возможно, стоит дать пользователям выбор хотят они обновлений или не хотят. Я просто уточняю анализ ситуации там, где, как мне кажется, его можно улучшить.