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

[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 - смотреть будем тупо там же, в ГК ? А что, мне нравится. А то понапридумывают фреймворков-шмеймфорков непонятных

[macklakov]

Цитата:

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

Скидки по оплате, просроченную дебиторку, курсовые, aging - смотреть будем тупо там же

Отличный пример! Именно об этом я говорю. Все эти вещи к AP практически никакого отношения не имеют. Это чистый AR. Зачем было городить искуственную иерархию сущностей, между которыми общего столько же, сколько и почти с любым другим модулем?
И зачем было в ГК встраивать возможность вести учет в разрезе клиента или единицы номенклатуры, когда есть специализированные модули?

[Vadik]

Цитата:

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

Отличный пример! Именно об этом я говорю. Все эти вещи к AP практически никакого отношения не имеют. Это чистый AR

Вы ошибаетесь. "Все эти вещи" вполне себе используются в AP (возможно, не на Вашем проекте, но это уже частности)

Цитата:

И зачем было в ГК встраивать возможность вести учет в разрезе клиента или единицы номенклатуры, когда есть специализированные модули?

Это всего-навсего возможность создавать entity backed финансовые аналитики в 2012. Где Вы там увидели учет и что Вы в это понятие вкладываете?

Цитата:

Зачем было городить искуственную иерархию сущностей, между которыми общего столько же, сколько и почти с любым другим модулем?

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

[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 приносит намного больше вреда чем пользы. Поэтому код по несколько тысяч строк - меньшее из зол.

[dech]

Цитата:

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

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

Полный бред. Вы соглашаетесь, что ООП - это хорошо и тут же пишете, что это плохо. С чего бы самому ООП быть злом? Может быть зло в тех, кто не умеет применять ООП? Я готов поспорить, в MS полно таких ребят. В АХ2012 появилось очень много "неправильной" архитектуры.
А почему? Могу сказать, что корень всего зла кроется в сжатых сроках, в рамках которых необходимо выполнить задачу. Чаще всего самый дебильный код получается тогда, когда ты с ошалевшими глазами стучишь по клавиатуре, и нет у тебя времени на рефакторинг своего кода.

[kashperuk]

Цитата:

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

Полный бред. Вы соглашаетесь, что ООП - это хорошо и тут же пишете, что это плохо. С чего бы самому ООП быть злом? Может быть зло в тех, кто не умеет применять ООП? Я готов поспорить, в MS полно таких ребят. В АХ2012 появилось очень много "неправильной" архитектуры.
А почему? Могу сказать, что корень всего зла кроется в сжатых сроках, в рамках которых необходимо выполнить задачу. Чаще всего самый дебильный код получается тогда, когда ты с ошалевшими глазами стучишь по клавиатуре, и нет у тебя времени на рефакторинг своего кода.

Интересно посмотреть примеры, что вы считаете неправильной архитектурой.
Не то чтобы я с вами не был согласен

[ax_mct]

Цитата:

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

Полный бред. Вы соглашаетесь, что ООП - это хорошо и тут же пишете, что это плохо. С чего бы самому ООП быть злом?

ERP как системе операций не нужно быть совокупностью объектов.

Бизнес это живой функционирующий организм который сегодня ходит на ногах, а завтра на руках.

SOP, SOA - здесь намного более уместнее чем OOP.

Грубо SOA это функция в которую мы передаем объекты, бизнес-процесс отделим от данных.
В то время как OOP это обьединение данных и функций как некое моделирование реальности.

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

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

ООП это как короткая юбка на темной улице.
Если бы Аксапта не поддерживала ООП то она былв бы сейчас живой.

[Bobkov]

Цитата:

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

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

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

[Pavel]

Цитата:

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

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

Минимум связей по данным не получится, потому фундаментом единного приложения (то что называют - РЕШЕНИЕ) является БАЗА ДАННЫХ, в отношении которой действуют законы нормализации (см. нормальные формы БД).

Разбить модули на независимые сервисы можно, но разделение данных нарушит нормализацию, вместо одной БД возникнет столько, сколько сервисов. Тогда возникнут новые проблемы... не менее интересные (кто занимался синхронизацией и репликацией распределенных данных, тот сталкивался).

[ax_mct]

Цитата:

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

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

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

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

В то время как ООП нельзя давать в руки адептов это религии в принципе, так как они сокрушат все стенки в доме просто потому что им так лучше видно. Проткнут насквозь все что можно проткнуть.

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