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

[Raven Melancholic]

Цитата:

контрагент.Действие() vs действие(Контрагент) это принципиальный подход.

Действительно принципиальный, вопрос в том, выбор одного из двух (трех, четырех, пяти ...) это абсолют или должно быть привязано к текущей задачи, к будущим задачам, к тому что знаем сейчас и к тому, что узнаем позже, можем ли при большем узнавании ситуации менять подход, сколько нам будет стоить это изменение, ну и всякие разности, связанные со словами Концепция и Архитектура.
Простой пример: Кот.Погладить, Погладить(Кот). Пока отвлечемся от русского языка и под погладить будем иметь ввиду не провести горячим утюгом, а нежно ладошкой провести от начала макушки до шеи.
Действие одно, а вот последствия разные и их бы нужно предусмотреть перед тем как выполнить это действие:

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

Нет универсальных вариантов как делать что-то определенное. Все эти паттерны, принципы не говорят что нужно делать только так, а никак иначе. Они просто предлагают, что есть вот такие возможности, а какими именно из них нужно следовать уже зависит от задачи. Только вот чтобы решить использовать ли эти вещи или эффективнее в определенных ситуациях их игнорировать, нужно простое правило - разработчик/архитектор все таки их должен знать.

[ax_mct]

Цитата:

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

...
Нет универсальных вариантов как делать что-то определенное. Все эти паттерны, принципы не говорят что нужно делать только так, а никак иначе. Они просто предлагают, что есть вот такие возможности, а какими именно из них нужно следовать уже зависит от задачи. Только вот чтобы решить использовать ли эти вещи или эффективнее в определенных ситуациях их игнорировать, нужно простое правило - разработчик/архитектор все таки их должен знать.

Именно что инструментарий.

Кому будет легче если сделать из одного метода settleNow() отдельный фрэймворк из пары десятков классов, документацию к нему по его API, затем патентовать костыли чтобы вызывать нужный класс.

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

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

[macklakov]

Цитата:

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

Если бы Жаба программировала человека, то для рта и ануса она бы создала РотАнус, с общими функциями/свойствами
сжать - разжать, туда-сюда, молчит - говорит.
Ну и супер-предка - Отверстие.

Это уже экстремизм! Сфинктер это отличный инжинерный паттерн. Не надо путать ора-анус со сфинктером.

[ax_mct]

Цитата:

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

Это уже экстремизм! Сфинктер это отличный инжинерный паттерн. Не надо путать ора-анус со сфинктером.

Мысль о том что прослойка между GUI и DB слишком много о себе вообразила - крайне интересна.
Это стоит подумать.

Цитата:

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

Доступ на уровне записей и сейчас лучше не использовать. Быстродействие убивает. Дело в другом. Дело именно в увлеченностью ООП.
ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно.
Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.

[ax_mct]

Цитата:

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

Точно, что для ERP главное это база данных? Разве не предметная область?
Когда я должен дать ответ по данным кассового чека, сколько покупатель может получить бонусов за эту покупку в зависимости от текущих акций, то какая разница получил ли я данные чека из базы, в которую он уже сохранен, получил ли этот чек прямым запросом из кассовой системы через Connector или получил его запросом через WEB сервис от консультанта торгового зала с планшета?

Хороший пойнт. Разные источники данных.
Можно и сказать что и GUI - главное. Но если смотреть в корень технической реализации то скорее таки база данных. Все остальное оболочка ввода и вывода.
Востребованная функциональность - это да. Но не важно как она реализована через простое ООП, сложное ООП или без ООП.

По хорошему создание X++ для обеспечения этой прослойки - было overengineering. Просто кто-то хотел был творцом. Возможно разумнее было использовать Java.
P.S. Но возможно это было обусловлено как эволюция XAL чтобы использовать уже существующий код - здесь я про overengineering только предполагаю.

[Pavel]

Цитата:

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

По хорошему создание X++ для обеспечения этой прослойки - было overengineering. Просто кто-то хотел был творцом. Возможно разумнее было использовать Java.
P.S. Но возможно это было обусловлено как эволюция XAL чтобы использовать уже существующий код - здесь я про overengineering только предполагаю.

Хмм... содержательная у вас тут дискуссия.)
Иногда заглядываю, что обсуждают кодеры в первых топиках и прихожу в ужас. Такая 'эволюция', просто как с навигатором по GPS в сортир дома ходить... а когда пропадает сигнал, 'забыв обо всем', решать вопросы со спутниками и коммуникациями.

Если отвлечься от 'бытовухи' и чисто ради 'академического интереса' задаться вопросом: насколько ООП сочетается/противоречит технологии слоев (своего рода полиморфизм) или системным номерам таблиц и полей (выделение диапазонов для ядра и доработки)? - то становится интересно мнение творцов этого синтеза.)

ООП это все не нужно, как самодостоточной технологии.

[belugin]

> Никому не нужна общность отверстий кроме программистского мозга.

Я знаю одно выражение, использующее общность отверстий. Там прямо квантор всеобщности и просторечное выражение обозначающее отверстия (но по контексту ясно что не имеются ввиду прорехи в одежды).

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

Я бы стал извлекать сведения из доменного специалиста или книжки, но мне влом.

В википедии:

"The anus (from Latin anus meaning "ring", "circle") is an opening at the opposite end of an animal's digestive tract from the mouth."

"In biological anatomy, commonly referred to as the mouth, under formal names such as the oral cavity, buccal cavity, or in Latin cavum oris,[1] is the opening through which many animals take in food and issue vocal sounds."

"Some animal phyla, including vertebrates, have a complete digestive system, with a mouth at one end and an anus at the other. Which end forms first in ontogeny is a criterion used to classify animals into protostome and deuterostome."

То есть у тех, у кого есть пищеварительная система на одном конце есть отверстие рот, на другом анус. Как эксплуатируется эта общность явно выраженная в википедии, фиг знает.

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

Просто этот результат нам привычен и лежит в чьей-то голове, из которой его можно выковырять.

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

Еще следует учесть, что формальные языки отличаются от естественных: что-то может подразумеваться по контексту, что-то быть сформулированно выражением, так что вполне может появится класс РотИлиАнус или типа того.

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

[ax_mct]

Цитата:

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

тем более, что непонятен контекст - хочет жаба лечить человека, препарировать его или кормить.
...
Еще следует учесть, что формальные языки отличаются от естественных: что-то может подразумеваться по контексту, что-то быть сформулированно выражением, так что вполне может появится класс РотИлиАнус или типа того.
...
Плохо придумывать свои термины, когда есть готовые, надо смотреть что люди уже успели наклассифицировать, но из-за ограничения скопа и ограничений формальных языков иногда полезно.

Ход мысли понятен. Моя ход в том что жаба не понимает что такое лечить или кормить. Ей просто надо разложить на части, в разные баночки по общности признаков.

Посыл мой в том что нахождение ООП общности в бизнес-логике - неуместно. Это привело к кросс-модульной организации и DB и кода. Более того ООП вообще вредно и ненужно для ERP.

[belugin]

Цитата:

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

Ход мысли понятен. Моя ход в том что жаба не понимает что такое лечить или кормить. Ей просто надо разложить на части, в разные баночки по общности признаков.

Тут мне ниже говорят, что в случае custvend общность признков-так есть и она полезна. И в исходном треде полно специалистов которые как мне кажется пришли к такому выводу

Цитата:

Посыл мой в том что нахождение ООП общности в бизнес-логике - неуместно. Это привело к кросс-модульной организации и DB и кода. Более того ООП вообще вредно и ненужно для ERP.

Что такое ООП-общность и чем она отличается от других видов общности?
Что такое "Кросс-модульная организация кода"?

[Pavel]

Цитата:

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

Посыл мой в том что нахождение ООП общности в бизнес-логике - неуместно. Это привело к кросс-модульной организации и DB и кода. Более того ООП вообще вредно и ненужно для ERP.

Поддерживаю. Надо было апдейтить ядро, совершенствуя технологии и оставить в покое бизнес-логику и БД, написанную на 4GL.

[macklakov]

Цитата:

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

Соответственно пример со ртом и анусом мне непонятен и почему вендор - взят из реальности, а контрагент - нет тоже

В учете есть множество устоявшихся классификаций, которые просто надо отразить в системе и весе. Никакого аналитического подвига. В AR и AP общее это Accounts. Это просто счет 2-й стороны сделки. Иначе говоря конт-агент. Все просто. И в это понятие совершенно естественным образом попадают и сотрудники и арендаторы и даже банки.
Есди продолжать проводить аналогии с биологической классификацией, то oris и anus объединили по каким-то общим признакам, а вот нос, желудок, верхние и средние разделы кишечника, протоки желез в эту классификацию почему-то не попали. При этом физиологически они сделаны разными, а вот перифирийная нервная система из одного узла активируется.

[belugin]

Цитата:

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

В учете есть множество устоявшихся классификаций, которые просто надо отразить в системе и весе. Никакого аналитического подвига. В AR и AP общее это Accounts. Это просто счет 2-й стороны сделки. Иначе говоря конт-агент. Все просто.

Цитата:

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

Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию.

Я так понял концепция поменялась - не слишком много обобщили, а недостаточно обобщили?

[macklakov]

Цитата:

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

Я так понял концепция поменялась - не слишком много обобщили, а недостаточно обобщили?

Одновременно и слишком много и недостаточно. А все потому, что не было понимания, что и зачем обообщают.
В принципе, в древних системах, в CustTrans и VendTrans нужды вообще не было. Ты просто делаешь аналитику Клиент по этим счетам ГК и прямо оттуда можешь баллансы смотреть. В 2012-ю как раз этот допотопный механизм и притащили с таким героическими усилиями. Именно для этого и созданны все эти account structures. Заполняешь аналитику Customer в проводке, которая идет в AR счет. А дальше когда надо проводки по этому клиенту посмотреть, или балланс, прямо из ГК и берешь. Там даже сопоставление есть. А на AP счетах у тебя аналитика Vendor. Тоже все просто. Все можно делать тупо через журлал ГК с типом счета Ledger.
И вот в системе у нас ГК, которая делает CustTrans, VendTrans ненужными. Но и CustVendTrans тоже никуда не неделись. При этом TaxTrans почему-то в эту чудесную иерархию не попадают. И payroll тоже. И даже для банков у нас какой-то причудливый reconciliation, который, по сути дела, тот же settlement, только чудовищно кривой.
Т.е. как раз дублирования в коде и функционале выше крыши. И чтобы это дублирование поддерживать, приходится писать всякие феерические reconciliation reports. Количество дублирования только нарастает. Но при этом произвольные куски вдруг покрыты иерархиями. В то время как другие вполне себе отдельно живут.

[Vadik]

Цитата:

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

Одновременно и слишком много и недостаточно. А все потому, что не было понимания, что и зачем обообщают.
В принципе, в древних системах, в CustTrans и VendTrans нужды вообще не было. Ты просто делаешь аналитику Клиент по этим счетам ГК и прямо оттуда можешь баллансы смотреть. В 2012-ю как раз этот допотопный механизм и притащили с таким героическими усилиями. Именно для этого и созданны все эти account structures. Заполняешь аналитику Customer в проводке, которая идет в AR счет. А дальше когда надо проводки по этому клиенту посмотреть, или балланс, прямо из ГК и берешь. Там даже сопоставление есть. А на AP счетах у тебя аналитика Vendor. Тоже все просто. Все можно делать тупо через журлал ГК с типом счета Ledger

Скидки по оплате, просроченную дебиторку, курсовые, aging - смотреть будем тупо там же, в ГК ? А что, мне нравится. А то понапридумывают фреймворков-шмеймфорков непонятных

[EVGL]

Цитата:

Никому не нужна общность отверстий кроме программистского мозга.

Для визуализации затронутой темы рекомендую к просмотру фильм "Человеческая многоножка". Фильм столь полюбился европейскому зрителю, что было выпущено два продолжения "Человеческая многоножка - 2" и "Человеческая многоножка - 3".

[ax_mct]

Цитата:

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

Тут мне ниже говорят, что в случае custvend общность признков-так есть и она полезна. И в исходном треде полно специалистов которые как мне кажется пришли к такому выводу
...
Что такое ООП-общность и чем она отличается от других видов общности?
Что такое "Кросс-модульная организация кода"?

У меня более радикальные взгляды чем у macklakov. Там где он соглашается что ООП можно если по здравому уму, я считаю что на здравость надеяться нельзя.

Прямо сейчас я делаю деплоймент своего кода в котором нет ООП но есть общность кода.
BlaBlaUtilBlaClass:romptBla_SalesLine(...)
BlaBlaUtilBlaClass:romptBla_item(...) где я вызываю первый метод создавая salesLine, то есть по сути wrapper.
Методы вызываются в седьми местах совсем разного кода где только больной будет искать ООП. Хотя если мне заплатят за ООП я его могу нарисовать на высшем Java уровне, я это умею. Но смысла в этом никакого нет. Все что мне нужно это вызывать общий код и менять его в одном месте. Тупо и надежно - все что мне нужно.

Кросс-модульная - это конечно я загибаю так как ERP это практически у всех (как я понимаю) исторически монолит, но по хорошему ООП должно ограничиваться границами модуля. Чтобы модуль был отделяемым и самостоятельным. Достаточно утопично поэтому и говорю что лучше вообше без ООП.
Систему на процедурах гораздо легче поделить на модули и по-моему намного проще расширять снаружи. Зачем не NAV, а AX положили на алтарь мне непонятно.

Цитата:

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

Хмм... содержательная у вас тут дискуссия.)
Иногда заглядываю, что обсуждают кодеры в первых топиках и прихожу в ужас. Такая 'эволюция', просто как с навигатором по GPS в сортир дома ходить... а когда пропадает сигнал, 'забыв обо всем', решать вопросы со спутниками и коммуникациями.

Если отвлечься от 'бытовухи' и чисто ради 'академического интереса' задаться вопросом: насколько ООП сочетается/противоречит технологии слоев (своего рода полиморфизм) или системным номерам таблиц и полей (выделение диапазонов для ядра и доработки)? - то становится интересно мнение творцов этого синтеза.)

ООП это все не нужно, как самодостоточной технологии.

Без ООП Аксапте было бы лучше. В то же время если бы она была реализована как Java EE то я бы радовался гораздо больше.

Цитата:

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

Для визуализации затронутой темы рекомендую к просмотру фильм "Человеческая многоножка". Фильм столь полюбился европейскому зрителю, что было выпущено два продолжения "Человеческая многоножка - 2" и "Человеческая многоножка - 3".

Именно что ООП как оно есть

[belugin]

Цитата:

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

ООП должно ограничиваться границами модуля. Чтобы модуль был отделяемым и самостоятельным.

Мне кажется вы в целом переизобретаете свою версию DDD

[ax_mct]

Цитата:

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

Мне кажется вы в целом переизобретаете свою версию DDD

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

Цитата:

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

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

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

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

[mazzy]

Computer, open pen
https://www.youtube.com/watch?v=nY7i7kj2jO4

[macklakov]

Мне вся эта ситуация с новой ГК видится вот как. Купил мужик на ebay 2 велика:


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