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

[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 обеспечивает нормальную инкапсуляцию, пряча детали внутрь класса.