Оver-engineering - "зачем так сложно?"

[Raven Melancholic]

Клиенты-поставщики всего лишь небольшая часть проблемы классификации, выделения общих и различающихся признаков и совсем не являются уникальной проблемой не только Аксапты, но даже и не связанной вообще с ERP. Большинство знает афоризм про определение того, к какой науке относится явление (если зеленое, то.., если пахнет, то…).
Почему их разделили в разные справочники, а потом нарисовали код, который их обрабатывает как что-то похожее? Ну принято было такое решение, ему и следуют и нам тоже приходится следовать. Другие варианты были? Конечно были, многие в других системах видели реализацию других вариантов. Лучше другие варианты или хуже? В одних ситуациях лучше, в других хуже.
Достаточно давно встречал описание того, как определить является ли архитектор приложения профессионалом. Если на вопрос «как правильно реализовать вот эту штуку?» начинаются ответы, что «вот только так..», то это новичок, профессионал начнет свой ответ «это смотря с какой стороны посмотреть…».
Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.? Тем более, что один и тот же реальный контрагент может выступать в одних сделках как клиент, в других как поставщик, в третьих как акционер – вариантов множество.
Проблема в отсутствии какого-то единого подхода в разделении и объединении. Понятно, что управлять взаимоотношениями с клиентами, поставщиками, сотрудниками, акционерами это совсем разные задачи. Понятно, что есть какие-то общие задачи – те же взаиморасчеты (но со своими нюансами с каждой категорией).
Будет ли каждая категория выделена в отдельный справочник и реализованы механизмы обработки общих принципов в отдельном семействе классов с деталями, зависящими от справочника или все категории слиты в один справочник и разные механизмы будут основываться на типе договора или на каком-то другом признаке не особенно важно. Хотелось бы, чтобы подход в разных частях системы был единым. Если делаем сопоставление, что почему для клиентов/поставщиков механизм один, а для подотчетников другой? Можно сказать, что для последних есть отличия, но так они и для клиентов/поставщиков есть – почему тогда не разделили сопоставление для клиентов/потавщиков?

[ax_mct]

Цитата:

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

...Ну а после того, как родился этот уродец с одним телом, но двумя головами, пошла поехала вся даунутая родня уродского семейства CustVend.
И Мапы таблиц придумали не от хорошей жизни, а как раз из-за необходимости одеть одну шапочку одновременно на две головы. (я ничего не имею против Мапов самих по себе. Решение интерфейсов к таблицам идеальное)

Одна шляпа - это программизм. Если бы и таблицы и код были отдельны и независимы всем было бы лучше. Кроме программистов которым больно смотреть на дублирование кода и данных.

Цитата:

Сообщение от Raven Melancholic

...Проблема в отсутствии какого-то единого подхода в разделении и объединении. Понятно, что управлять взаимоотношениями с клиентами, поставщиками, сотрудниками, акционерами это совсем разные задачи. Понятно, что есть какие-то общие задачи – те же взаиморасчеты (но со своими нюансами с каждой категорией).
Будет ли каждая категория выделена в отдельный справочник и реализованы механизмы обработки общих принципов в отдельном семействе классов с деталями, зависящими от справочника или все категории слиты в один справочник и разные механизмы будут основываться на типе договора или на каком-то другом признаке не особенно важно. Хотелось бы, чтобы подход в разных частях системы был единым...

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

Объектный взгляд на мир когда объект.функциональность - он вреден в системе предоставляющей бизнес-функции.
Модуль Закупки - это Закупать.
Модуль Продажи - Продавать.
В модуле Закупаем нам не нужны клиенты, а только поставщики.
В модуле Продаём нам не нужны поставщики.
Модуль - это модуль.
Там где функции ценообразования в продажах нужна информация о поставщиках,
это функциональный вопрос, но не объектная общность по признакам.

ООП должно быть подчинено процессу и обслуживать процесс.
Не контрагент.Действие(), а действие(Контрагент).
Никому не нужна общность отверстий кроме программистского мозга.
"Принимать пищу", "Усвоить пищу", "Выводить усвоенное" - реализация этих функций нужна, а не реализация "рот беззубый зеркальный". И сколько бы не было мнимого дублирования - если это повышает независимость и надёжность, то и замечательно.

[Raven Melancholic]

Цитата:

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

Программистский подход - искать общее, объединять.

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

Ответил в Курилке.
Оver-engineering - "зачем так сложно?" - Мортира Карл

Именно что программистский учет не должен отражать то чего нет в реальности. Дублирование кода - наименьшее зло.

Цитата:

так как вендор и кастер (ну предположим Вася Пупкин) совершенно разные единицы в управленческом и бухгалтерском учете.

[macklakov]

Цитата:

Сообщение от Raven Melancholic

.Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.? Тем более, что один и тот же реальный контрагент может выступать в одних сделках как клиент, в других как поставщик, в третьих как акционер – вариантов множество.

Вот именно! Само понятие контрагента, т.е. счета второй стороны сделки, действительно общее для всех процессов. Причем общее с точки зрения бизнеса.
А из-за того что такого понятия нет, в AX крайне поддерживать баланс контрагента крайне сложно. К примеру, если это компания-партнер, которая покупает товары, оказывает вам услуги, берет у вас в долг и держит на руках ваши акции. А еще они одалживают оборудование и дают свой товар на ответственное хранение. И вот мы должны посмотреть, кто чего и кому должен... И вот здесь все становится очень сложно. Без хитрых фреймворков такой функционал станет совершенно несопровождаемым.
Но причина-то ведь не в ООП! Причина в ошибках дизайна БД! Именно из-за того что структура таблиц неадекватно отражает бизнс-сущности, и возникает необходимость применять высший архитектурный пилотаж. Ярчайший пример, новая ГК, не к ночи будет помянута. Ради нее одной огромное количество новшеств в программную среду внесено. ГК это ведь такая простая вещь, по своей сути. В каждой второй смописке есть и почти никогда это не является bottleneck. Но у нас это чудовищный монстр, забивающий базу с экспоненциальной скростью, из-за чего система начинает тормозить уже на среднем объеме проводок.

[EVGL]

Цитата:

Сообщение от Raven Melancholic

Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.?

Не отличается. Вы уж извините за подотчетных лиц, грехи молодости, а нынешнее поколении локализаторов никак не вырежет их нафиг. В стандарте сотрудника можно ассоциировать с поставщиком и оплачивать за один проход. На текущем проекте сделал так, чтобы запись в таблице поставщиков создавалась автоматически, а синхронизация имени идет через ГАК. Аналогично, по государству = налоговому органу автоматически формируется задолженность в РсП.

Однако, задачи модулей РсП и РсК отличаются: в одном случае есть задача платить как можно позднее (все это казначейство, бюджеты и тп) а в другом - получить деньги как можно быстрее (инкассо, collections, cash flow). Поэтому смотреть на это как на одну сущность - это упрощение.

[gl00mie]

Мне кажется, в Аксапте изначально всё довольно логично было спроектировано: вот есть отдельный модуль, у него есть свои основные сущности, есть движения по этим сущностям, есть журналы, которыми пользователям удобнее вводить информацию об этих движениях, есть запросы и отчеты, ну и еще настройки модуля. Далее, по ходу реализации выяснялось, что у модулей РСК и РСП много общего, а у других модулей - не так вроде много, поэтому ленивые программисты стали пытаться избавляться от копипаста и выносить общую бизнес-логику. Справочники так и не объединили, потому что по изначальной задумке они в каждом модуле - свои. Но общие вещи в итоге-таки вынесли в тот же ГАК.
Объективно ERP автоматизирует достаточно сложные сущности и процессы окружающего мира, и это определяет некий минимальный порог сложности самой системы. А разработка ПО крутится, с одной стороны, вокруг борьбы со сложностью, а с другой, - вокруг повторного использования кода. Две эти задачи неплохо решаются с помощью ООП, поэтому логично, что в Аксапте как сложной системе ООП используется достаточно широко и для борьбы со сложностью, и для повторного использования кода. Конечно, есть "перекосы на местах", конечно, кое-где выделение общей логики для повторного использования подчас сделано топорно и приносит больше проблем, чем пользы, особенно когда имеешь дело с методами в сотни строк кода. Но не стоит, по-моему, с водой выплескивать и ребенка, заявляя, что все проблемы Аксапты - от ООП.

[ax_mct]

Цитата:

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

Может, надо было нашлепать по отдельной таблице на каждый тип журнала ГК и УЗ, а в разноске тупо копипастить общую логику?

А почему нет? Если "нет" только потому что это не соответствует ООП и нежеланию копипастить, то да, лучше нашлепать и тупо копипастить общую логику.

Цитата:

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

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

Проблемы Аксапты не от ООП как полезного инструмента, а от того что что вместо инструмента это стало религией для слишком многих. Любой код и таблицу можно "нормализовывать". Все знают о шести нормальных формах в проектировании БД,
но к сожалению таких четких форм нормальности/достаточности ООП - нет.

Мысль macklakov мне кажется очень интересной.

Цитата:

Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.

[Logger]

Да не в SQL все дело.
А в оторванности от практики людей, создающих прикладной код аксапты.

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

[George Nordic]

Угу, тем более что контрагент может быть одновременно и поставщиком, и покупателем.

С Уважением,
Георгий

[ax_mct]

У меня сейчас одна из задач в AX2012 обеспечить установку primary vendor на уровне site в разрезе customer/customer group.

ООП вроде бы крутое везде и всюду с наследованием контрактов и прочим, а мне надо искать и заменять все вхождения inventTable.PrimaryVendor на что-то типа salesLine.getPrimaryVendor().

ООП надо чтобы salesLineType.getPrimaryVendor() то есть расширение конкретной функциональности, а не затем чтобы переставлять технический код местами чтобы расчлененка была более кровавой.
При этом если бы не было в системе ООП вообще а было что-то типа процедурно getPrimaryVendor_SalesLine(salesLine) то я бы не плакал. И клиент не рыдал

То есть пользы от ООП в АX я не вижу, только вред.

[belugin]

Цитата:

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

ООП вроде бы крутое везде и всюду с наследованием контрактов и прочим, а мне надо искать и заменять все вхождения inventTable.PrimaryVendor на что-то типа salesLine.getPrimaryVendor().

Это значит, что не всюду вот в этом конкретном месте (в таблицах) нет инкапсуляции.

[Morpheus]

Цитата:

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

То есть пользы от ООП в АX я не вижу, только вред.

Методы, содержащие по несколько тысяч строк, написаны разделяющими Ваше мнение людьми.

[dech]

Цитата:

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

При этом если бы не было в системе ООП вообще а было что-то типа процедурно getPrimaryVendor_SalesLine(salesLine) то я бы не плакал. И клиент не рыдал

То есть пользы от ООП в АX я не вижу, только вред.

Технически код

vendor = salesLine.getPrimaryVendor();

трактуется компилятором так:

vendor = SalesLine::getPrimaryVendor(salesLine);

где SalesLine тупо работает как scope, т.е. область видимости, а salesLine - табличная переменная.
сам метод интерпретируется как

public VendTable getPrimaryVendor(SalesLine _salesLine)
{
;
    this = _salesLine;
    ...
}

Работа с this происходит неявно и нам удобнее работать с меньшим числом параметров. Но дело не в этом.
ООП предназначено для другого: наследование, инкапсуляция и полиморфизм. Не будь наследования, мы бы погрязли в дублировании кода. Полиморфизм позволяет работать с базовым классом, и не держать руку на пульсе, каждый раз спрашивая себя, а с функцией какой сущности (то бишь класса) я работаю?
Вот инкапсуляция - это да, она конкретно не доработана. Очень не хватает свойств, хотя методы доступа get/set/parm есть, но с ними не так удобно.

[dech]

Если подумать, то и наследование таблиц - также over-engineering. При нормализации таблиц уже до 3-й формы наследование излишне. У меня когда-то лет 7 назад была идея, а что если у таблиц сделать наследование полей, как в ООП... начал ковырять и пришел к нормализации таблицы :-)

[Vadik]

Цитата:

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

Если подумать, то и наследование таблиц - также over-engineering. При нормализации таблиц уже до 3-й формы наследование излишне

мне кажется, это была попытка сначала нормализовать структуру данных "правильно, по тру-программистски", а когда стало очевидно что любое обращение к ней требует соединения дюжины-двух таблиц - материализовать эту структуру. Правильно это или нет - сказать сложно. В AOT смотришь - вроде удобно и логично, в DirPartyTable в БД - кровавое месиво какое-то. Но в целом - работает

[dech]

Цитата:

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

мне кажется, это была попытка сначала нормализовать структуру данных "правильно, по тру-программистски", а когда стало очевидно что любое обращение к ней требует соединения дюжины-двух таблиц - материализовать эту структуру. Правильно это или нет - сказать сложно. В AOT смотришь - вроде удобно и логично, в DirPartyTable в БД - кровавое месиво какое-то. Но в целом - работает

Я бы посмотрел в сторону View, но они в аксапте как-то не очень активно используются, например по сравнению с WEB-системами. Если глянуть тот же Wordperss или Drupal, там вьюхи используются чуть ли не чаще, чем сами таблицы. Да и поддержка на уровне БД. Тем более, что обычно нужны не все поля, а некоторый набор. Другое дело, когда на разные нужды требуются разные наборы полей.

[fed]

По моему, главная проблема с наследованием таблиц в Ax - это решение о том что родитель содержит в себе все поля всех наследников. Из за этого им пришлось в ранних версиях автоматически делать outer join родителя ко всем наследникам, а в поздних версиях - просто складывать все поля наследников в одну большую таблицу-родителя.
В классической системе мэппинга объектных отношений в реляционную БД, обращение к таблице наследнику, неявно делает inner join с таблицей родителем. В обращение к родителю ни к каким автоматическим join не приводит. Из за того что MS решил пойти своим путем, использование наследования привело к большому оверхиду - либо из за джойнов, либо из за тучи неиспользуемых полей в таблице.

[gl00mie]

Цитата:

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

По моему, главная проблема с наследованием таблиц в Ax - это решение о том что родитель содержит в себе все поля всех наследников. Из за этого им пришлось в ранних версиях автоматически делать outer join родителя ко всем наследникам, а в поздних версиях - просто складывать все поля наследников в одну большую таблицу-родителя.

Так была ведь задача выбрать запись из иерархии таблиц, не зная изначально точный "тип" записи, а потом, уже после выборки, иметь возможность сделать приведение типа к нужному наследнику и дальше работать с записью таблицы-наследника без перевыборки данных. Вариант с кучей outer join'ов оказался нежизнеспособным с т.з. производительности, пришли к одной таблице с полями всех-всех наследников, в которых могут быть значения NULL. Какие еще были варианты решить исходную задачу?..

Цитата:

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

В классической системе мэппинга объектных отношений в реляционную БД, обращение к таблице наследнику, неявно делает inner join с таблицей родителем. В обращение к родителю ни к каким автоматическим join не приводит.

Это хорошо работает, если заранее знать конкретный тип сущности, к которой идет обращение, и если не стоит задача последующего приведения типа родителя к наследнику.
Собственно, чем именно не нравится то, как это реализовано в Аксапте? Да, ядро всегда выбирает набор полей, равный объединению множеств полей всех таблиц-наследников для типа, "через который" идет обращение к таблице в иерархии. Так, если выбирать записи через DirPartyTable, то в выборку попадет под 150 полей (не считая DEL_-полей). Но если заранее более точно знать тип и выбирать, к примеру, DirPerson, то в выборке будет уже лишь 40 полей. При этом выборка через DirPartyTable даст в тех или иных записях кучу полей, содержащих NULL, ну и что с того? Длину строки SQL-запроса это увеличивает, но лишних данных, кроме тех, которые могут понадобиться для приведения к типам-наследникам, не гоняет.

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

[fed]

Цитата:

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

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

Ну по моему - такая ситуация и случается в большинстве случаев. Если нужно сделать какой-то универсальный обработчик, то разумнее пробежаться в таблице супео-класса, и тупо потом найти конкретные потомки find'ом. А при нынешнем подходе, оно вытаскивает вообще всех потомков, хотя у меня в обработчике может быть логика только для 2-3 кейзов (а тяжелый outer join строится для всех кейзов, а не только для тех, которые мне реально нужны).