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

[Vadik]

Цитата:

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

скидки по оплате и aging? можешь описать как и зачем?

Это вопрос с подвохом ? Так же и затем же, что и в AR. "Оплати быстро и получи скидку", "кому, сколько и когда мы должны платить". По курсовым, я так понял, вопросов не возникло? Тогда предположу, что "искуственные иерархии сущностей" не такие уж и искуственные, и схожего в задачах реализуемых в AR и AP достаточно ? И (осторожно, крамола) даже возможно ограниченное применение ООП ?

Цитата:

Зачем такие аналитики нужны? Я вот видел системы где счета через черточку и AR это буквальным образом счет accounts receivable в ГК и один из сегментов это именно клиент

Клиент в качестве аналитики ГК - это один из способов разнообразить свою сексуальную жизнь в конце года при выверке GL с AR. Ну и отчасти признак качественного внедрения

Цитата:

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

Ну вот, а 8 часов назад собирались AR с AP упразднять за ненужностью

Цитата:

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

[macklakov]

Цитата:

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

Это вопрос с подвохом ? Так же и затем же, что и в AR. "Оплати быстро и получи скидку"

Так, вот здесь ты меня потерял. Ты хочешь сказать что контора закупила товар, держала его какое-то время, потом проплатила, потом решила вернуть поставщику. Не поменять, а именно вернуть. Правильно? И у поставщика этого закупают очень редко, поэтому вместо взаимозачета идет выбивание бабла. И поставщик этот бабло возвращать не торопится. Но реагирует на скидку по оплате. И при этом это происходит так часто, что надо настраивать эти самые скидки и даже collections?

Цитата:

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

Клиент в качестве аналитики ГК - это один из способов разнообразить свою сексуальную жизнь в конце года при выверке GL с AR. Ну и отчасти признак качественного внедрения

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

[macklakov]

Цитата:

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

Ну вот, а 8 часов назад собирались AR с AP упразднять за ненужностью

Ну до подмены-то опускаться не надо. Я говорил про конкретные таблицы CustTrans и VendTrans. С новой ГК, позаимствованной из GP, эти таблицы больше не нужны. Если у тебя счет AR ведется в разрезе Customer, ты ageing report прекрасно по проводкам ГК построить можешь. И скидки по оплате тоже.
Продолжая аллегорию. На велосипеде теперь 2 набора педалей. Один из них явно избыточный.

[macklakov]

Цитата:

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

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

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

[EVGL]

Цитата:

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

Ну, в принципе, согласен. Можно. В реальности так делать приходилось?

Да, конечно. В Австрии вообще все помешаны на скидках по оплате, согласно best practices учета запасы принимаются к учету за вычетом скидки. Исходят из того, что в 99% случаев покупатель воспользуется скидкой, и последняя учитывается не как доход текущего периода, а снижает стоимость актива.

[Vadik]

Цитата:

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

Ну до подмены-то опускаться не надо. Я говорил про конкретные таблицы CustTrans и VendTrans. С новой ГК, позаимствованной из GP, эти таблицы больше не нужны. Если у тебя счет AR ведется в разрезе Customer, ты ageing report прекрасно по проводкам ГК построить можешь. И скидки по оплате тоже

Было интересно следить за развитием ветки. В MS понятия не имеют о проектировании ПО и внедрениях (ну, кто бы сомневался). Плавное развитие темы до легких БМП с титановыми крыльями, ора-анусов, велосипедов - мне было интересно. Теперь я могу с чистой совестью отписаться. Я уже видел все

[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".

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

[macklakov]

Цитата:

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

Теперь я могу с чистой совестью отписаться

Еще один вопрос, пожалуйста. Как так получилось, что банк это не party?

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

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

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

[macklakov]

Цитата:

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

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

Да речь-то о том что архитектура зачастую потрясает. Не ожидаешь таких наворотов от системы, со сравнительно узкой нишей. Но лучше бы в системе не создавали тех проблем, которые приводят к необходимости использовать изощренную архитектуру.
Изрядная часть этих изысков результат пересадки ГК из GP в AX. При том что вся логика модулей не рассчитана на работу с такой ГК. Я когда на это смотрю, каждый раз поражаюсь таланту архитекторов и программистов, которые таки заставили подобное решение хоть как-то работать.
Хотя, к банковскому модулю вопросы есть, конечно. Перемудрили на ровном месте.

[dech]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

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

Я скажу так, цель ООП - в первую очередь облегчить понимание кода, перейти на новый уровень абстракций. Например если проводишь манипуляции не с какой-либо функцией, на входе которой 5-7 (а то и >10) параметров строкового типа, а с методом, часть данных которого уже хранится в экземпляре класса, а другая часть передается в виде одного-двух объектов.
Я не понимаю, что вы хотите получить, отделяя бизнес-процесс от данных? швейцарский нож, который может и секатором работать, и бензопилой?))) Каждый объект данных требует своей собственной обработки. Вам не уйти от ООП, как бы вам этого ни хотелось.

Насчет понимания, приведу пример. Есть два класса, которые делают некоторый расчет суммы по оплате немного по-разному. Вроде всё круто, всего 1 метод перекрывается в классах наследниках. Но если изучать его работу (пример здесь очень простой, на практике всё в разы сложнее, сами понимаете), можно запутаться, либо долго тупить.

class Site
{
    real units;
    real rate;
    real taxRate;

    public abstract real getBillableAmount();
}

class ResidentalSite extends Site
{
    public real getBillableAmount()
    {
        real base = units * rate;
        real tax = base * taxRate;

        return base + tax;
    }
}

class LifelineSite extends Site
{
    public real getBillableAmount()
    {
        real base = units * rate * 0.5;
        real tax = base * taxRate * 0.2;

        return base + tax;
    }
}

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

class Site
{
    real units;
    real rate;
    real taxRate;

    public real getBillableAmount()
    {
        return this.getBaseAmount() + this.getTaxAmount();
    }

    protected abstract real getBaseAmount();
    protected abstract real getTaxAmount();
}

class ResidentalSite extends Site
{
    protected real getBaseAmount()
    {
        return units * rate;
    }

    protected real getTaxAmount()
    {
        return this.getBaseAmount() * taxRate;
    }
}

class LifelineSite extends Site
{
    protected real getBaseAmount()
    {
        return units * rate * 0.5;
    }

    protected real getTaxAmount()
    {
        return this.getBaseAmount() * taxRate * 0.2;
    }
}

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

[Pavel]

Цитата:

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

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

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

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

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

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

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

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

Речь же идет не об абстрактной ПРОГРАММЕ, написанной в той или иной концепции программирования??

Здесь совершенно конкретное направление приложений - СУБД. Те суть-данные организованы в записи таблиц, а не есть содержание объектов (экзепляров классов).
Методы обработки данных - это суть БИЗНЕС-ПРИЛОЖЕНИЯ, те бизнес-логика, реализованная с помощью классических элементов СУБД(процедуры, функции, триггеры, списки, макросы, формы, отчеты, запросы, меню и тд).
Аналогом полиморфизма в ООП служили слои, те когда разработчик менял менял не сам объект, а создавал актуальную для приложения его копию.

Еще есть ЯДРО, которое может быть написано на чем угодно, под любую среду и интерфейс. Ядро должно использовать бизнес-логику как некую библиотеку сущностей, а само решать все технологические аспекты по отношению к аппаратному и программному обеспечению, на котором работает приложение.

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

Наверное можно было всю эту работу с БД организовать через концепцию ООП, но в Аксапте - этого точно не получилось. Вышло классическая приложение СУБД с приблудой в виде ООП, которая по сути нужна приложению... 'как зайцу стоп-сигнал'(с).

[Pavel]

Цитата:

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

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

Интересно, что же такое пересадили в ГК из GP в АХ, необходимое не ради 'архитектуры', а как часть развития бизнес-приложения... то что модно называть громким словом - РЕШЕНИЕ?!

пс. Чего там так не хватало))))

[ax_mct]

Цитата:

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

Я скажу так, цель ООП - в первую очередь облегчить понимание кода, перейти на новый уровень абстракций. Например если проводишь манипуляции не с какой-либо функцией, на входе которой 5-7 (а то и >10) параметров строкового типа, а с методом, часть данных которого уже хранится в экземпляре класса, а другая часть передается в виде одного-двух объектов.
...
Насчет понимания, приведу пример. Есть два класса, которые делают некоторый расчет суммы по оплате немного по-разному.

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

В приведенном примере нам надо сделать подсчет, а не моделировать поведение обьекта Site.
Объектное мышление здесь только вредит. VB6 или даже VBA здесь достаточно. Скрывать в инкапсуляции здесь нечего и незачем.

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

Цитата:

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

Я не понимаю, что вы хотите получить, отделяя бизнес-процесс от данных? швейцарский нож, который может и секатором работать, и бензопилой?))) Каждый объект данных требует своей собственной обработки. Вам не уйти от ООП, как бы вам этого ни хотелось.
...
Но именно protected обеспечивает нормальную инкапсуляцию, пряча детали внутрь класса.

Абстрагироваться надо не от реальности, а от неуместного ООП.
Pavel 200 раз прав про уместность.

Цитата:

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

Здесь совершенно конкретное направление приложений - СУБД. Те суть-данные организованы в записи таблиц, а не есть содержание объектов (экзепляров классов).
Методы обработки данных - это суть БИЗНЕС-ПРИЛОЖЕНИЯ, те бизнес-логика, реализованная с помощью классических элементов СУБД(процедуры, функции, триггеры, списки, макросы, формы, отчеты, запросы, меню и тд).
...
В плане инкапсуляции данных, которая по сути обеспечивает сохранность данных и устойчивость работы приложения... все было в порядке и без ООП. А именно текущие переменные объявлялись и использовались в методах (процедуры, запросы, макросы, триггеры, меню, формы, отчеты,...), а все так сказать 'глобальные' внешние переменные оказались организованы в записи таблиц БД.

Наверное можно было всю эту работу с БД организовать через концепцию ООП, но в Аксапте - этого точно не получилось. Вышло классическая приложение СУБД с приблудой в виде ООП, которая по сути нужна приложению... 'как зайцу стоп-сигнал'(с).

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

ERP как набору workflow и на реляционной СУБД - ООП только во вред. Потому как используется только для оverengineering подавляющим большинством программистов.

[Bobkov]

Цитата:

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

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

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