AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 27.06.2017, 16:22   #41  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
 
3,275 / 1274 (49) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от 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 ненужными
__________________
-ТСЯ или -ТЬСЯ ?
Старый 27.06.2017, 16:57   #42  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,940 / 832 (31) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Vadik Посмотреть сообщение
Это вопрос с подвохом ? Так же и затем же, что и в AR. "Оплати быстро и получи скидку"
Так, вот здесь ты меня потерял. Ты хочешь сказать что контора закупила товар, держала его какое-то время, потом проплатила, потом решила вернуть поставщику. Не поменять, а именно вернуть. Правильно? И у поставщика этого закупают очень редко, поэтому вместо взаимозачета идет выбивание бабла. И поставщик этот бабло возвращать не торопится. Но реагирует на скидку по оплате. И при этом это происходит так часто, что надо настраивать эти самые скидки и даже collections?

Цитата:
Сообщение от Vadik Посмотреть сообщение
Клиент в качестве аналитики ГК - это один из способов разнообразить свою сексуальную жизнь в конце года при выверке GL с AR. Ну и отчасти признак качественного внедрения
Это штатная возможность, которую вендор впаривает клиентской бухгалтерии, переезжающей с допотопных консольных систем на AX. Ты будешь спорить с рекомендацией вендора?
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 27.06.2017 в 17:09.
Старый 27.06.2017, 17:01   #43  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,940 / 832 (31) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Vadik Посмотреть сообщение
Ну вот, а 8 часов назад собирались AR с AP упразднять за ненужностью
Ну до подмены-то опускаться не надо. Я говорил про конкретные таблицы CustTrans и VendTrans. С новой ГК, позаимствованной из GP, эти таблицы больше не нужны. Если у тебя счет AR ведется в разрезе Customer, ты ageing report прекрасно по проводкам ГК построить можешь. И скидки по оплате тоже.
Продолжая аллегорию. На велосипеде теперь 2 набора педалей. Один из них явно избыточный.
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 27.06.2017 в 17:16.
Старый 27.06.2017, 17:08   #44  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,940 / 832 (31) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от EVGL Посмотреть сообщение
Легко. В пересчете на год процент скидки по оплате обычно заведомо превышает ставку рефинансирования, поэтому экономически выгодно платить поставщику в последний день действия скидки по оплате если последняя предоставляется. Такую стратегию можно выбрать в предложениях по оплате.
Ну, в принципе, согласен. Можно. В реальности так делать приходилось?
У нас, просто, это делается письмами-напоминаниями, которые суть забота поставщика. По этой причине назревающие платежи отражены лишь в cash flow. А cash flow все одно самописный.
__________________
Isn't it nice when things just work?
Старый 27.06.2017, 17:22   #45  
EVGL is offline
EVGL
Moderator
Лучший по профессии 2014
Соотечественники
 
3,466 / 1896 (70) ++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от macklakov Посмотреть сообщение
Ну, в принципе, согласен. Можно. В реальности так делать приходилось?
Да, конечно. В Австрии вообще все помешаны на скидках по оплате, согласно best practices учета запасы принимаются к учету за вычетом скидки. Исходят из того, что в 99% случаев покупатель воспользуется скидкой, и последняя учитывается не как доход текущего периода, а снижает стоимость актива.
Старый 27.06.2017, 18:47   #46  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
 
3,275 / 1274 (49) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от macklakov Посмотреть сообщение
Ну до подмены-то опускаться не надо. Я говорил про конкретные таблицы CustTrans и VendTrans. С новой ГК, позаимствованной из GP, эти таблицы больше не нужны. Если у тебя счет AR ведется в разрезе Customer, ты ageing report прекрасно по проводкам ГК построить можешь. И скидки по оплате тоже
Было интересно следить за развитием ветки. В MS понятия не имеют о проектировании ПО и внедрениях (ну, кто бы сомневался). Плавное развитие темы до легких БМП с титановыми крыльями, ора-анусов, велосипедов - мне было интересно. Теперь я могу с чистой совестью отписаться. Я уже видел все
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: EVGL (1), belugin (2).
Старый 27.06.2017, 22:22   #47  
EVGL is offline
EVGL
Moderator
Лучший по профессии 2014
Соотечественники
 
3,466 / 1896 (70) ++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Никому не нужна общность отверстий кроме программистского мозга.
Для визуализации затронутой темы рекомендую к просмотру фильм "Человеческая многоножка". Фильм столь полюбился европейскому зрителю, что было выпущено два продолжения "Человеческая многоножка - 2" и "Человеческая многоножка - 3".
Старый 28.06.2017, 02:24   #48  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,572 / 507 (20) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от belugin Посмотреть сообщение
Тут мне ниже говорят, что в случае custvend общность признков-так есть и она полезна. И в исходном треде полно специалистов которые как мне кажется пришли к такому выводу
...
Что такое ООП-общность и чем она отличается от других видов общности?
Что такое "Кросс-модульная организация кода"?
У меня более радикальные взгляды чем у macklakov. Там где он соглашается что ООП можно если по здравому уму, я считаю что на здравость надеяться нельзя.

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

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


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

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

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

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


Последний раз редактировалось ax_mct; 28.06.2017 в 02:38. Причина: Заменил размер jpg
За это сообщение автора поблагодарили: macklakov (1).
Старый 28.06.2017, 02:29   #49  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,940 / 832 (31) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Vadik Посмотреть сообщение
Теперь я могу с чистой совестью отписаться
Еще один вопрос, пожалуйста. Как так получилось, что банк это не party?
__________________
Isn't it nice when things just work?
Старый 28.06.2017, 09:00   #50  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,903 / 2027 (75) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
ООП должно ограничиваться границами модуля. Чтобы модуль был отделяемым и самостоятельным.
Мне кажется вы в целом переизобретаете свою версию DDD
Старый 28.06.2017, 14:38   #51  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,572 / 507 (20) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от belugin Посмотреть сообщение
Мне кажется вы в целом переизобретаете свою версию DDD
То что модуль ERP должен быть самодостаточным доменом - это на самом деле золотая идея. Те же микро-сервисы но уровне модулей ERP.
ООП без границ модулей - создало неподьемный монолит.

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

ООП - это хороший инструмент, но ООП для бизнес-логики ERP приносит намного больше вреда чем пользы. Поэтому код по несколько тысяч строк - меньшее из зол.
Старый 13.07.2017, 21:17   #52  
dech is offline
dech
Участник
Аватар для dech
 
421 / 176 (6) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Цитата:
Сообщение от ax_mct Посмотреть сообщение
ООП - это хороший инструмент, но ООП для бизнес-логики ERP приносит намного больше вреда чем пользы.
Полный бред. Вы соглашаетесь, что ООП - это хорошо и тут же пишете, что это плохо. С чего бы самому ООП быть злом? Может быть зло в тех, кто не умеет применять ООП? Я готов поспорить, в MS полно таких ребят. В АХ2012 появилось очень много "неправильной" архитектуры.
А почему? Могу сказать, что корень всего зла кроется в сжатых сроках, в рамках которых необходимо выполнить задачу. Чаще всего самый дебильный код получается тогда, когда ты с ошалевшими глазами стучишь по клавиатуре, и нет у тебя времени на рефакторинг своего кода.
__________________
// no comments
Старый 13.07.2017, 21:43   #53  
kashperuk is offline
kashperuk
Senior SDE, Dynamics AX
Аватар для kashperuk
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
 
4,287 / 1948 (73) ++++++++
Регистрация: 30.05.2004
Адрес: Копенгаген, Дания
Цитата:
Сообщение от dech Посмотреть сообщение
Полный бред. Вы соглашаетесь, что ООП - это хорошо и тут же пишете, что это плохо. С чего бы самому ООП быть злом? Может быть зло в тех, кто не умеет применять ООП? Я готов поспорить, в MS полно таких ребят. В АХ2012 появилось очень много "неправильной" архитектуры.
А почему? Могу сказать, что корень всего зла кроется в сжатых сроках, в рамках которых необходимо выполнить задачу. Чаще всего самый дебильный код получается тогда, когда ты с ошалевшими глазами стучишь по клавиатуре, и нет у тебя времени на рефакторинг своего кода.
Интересно посмотреть примеры, что вы считаете неправильной архитектурой.
Не то чтобы я с вами не был согласен
За это сообщение автора поблагодарили: Logger (1).
Старый 13.07.2017, 22:33   #54  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,572 / 507 (20) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от dech Посмотреть сообщение
Полный бред. Вы соглашаетесь, что ООП - это хорошо и тут же пишете, что это плохо. С чего бы самому ООП быть злом?
ERP как системе операций не нужно быть совокупностью объектов.

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

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

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

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

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

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

Последний раз редактировалось ax_mct; 13.07.2017 в 22:36.
Старый 14.07.2017, 02:28   #55  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,940 / 832 (31) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Интересно посмотреть примеры, что вы считаете неправильной архитектурой.
Да речь-то о том что архитектура зачастую потрясает. Не ожидаешь таких наворотов от системы, со сравнительно узкой нишей. Но лучше бы в системе не создавали тех проблем, которые приводят к необходимости использовать изощренную архитектуру.
Изрядная часть этих изысков результат пересадки ГК из GP в AX. При том что вся логика модулей не рассчитана на работу с такой ГК. Я когда на это смотрю, каждый раз поражаюсь таланту архитекторов и программистов, которые таки заставили подобное решение хоть как-то работать.
Хотя, к банковскому модулю вопросы есть, конечно. Перемудрили на ровном месте.
__________________
Isn't it nice when things just work?
Старый 14.07.2017, 12:28   #56  
dech is offline
dech
Участник
Аватар для dech
 
421 / 176 (6) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Интересно посмотреть примеры, что вы считаете неправильной архитектурой.
Не то чтобы я с вами не был согласен
Прям так сразу я наверное не смогу привести лаконичный пример. Просто реально много никому ненужных наворотов. Попробую на выходных что-нибудь нарыть...
Цитата:
Сообщение от ax_mct Посмотреть сообщение
ERP как системе операций не нужно быть совокупностью объектов.

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

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

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

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

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

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

Насчет понимания, приведу пример. Есть два класса, которые делают некоторый расчет суммы по оплате немного по-разному. Вроде всё круто, всего 1 метод перекрывается в классах наследниках. Но если изучать его работу (пример здесь очень простой, на практике всё в разы сложнее, сами понимаете), можно запутаться, либо долго тупить.
X++:
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;
    }
}
Но если немного подумать, можно выделить общую часть алгоритма в базовый класс, тем самым упростив понимание:
X++:
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 обеспечивает нормальную инкапсуляцию, пряча детали внутрь класса.
__________________
// no comments
Старый 14.07.2017, 13:24   #57  
Pavel is offline
Pavel
SAP
SAP
 
2,714 / 230 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от ax_mct Посмотреть сообщение
ERP как системе операций не нужно быть совокупностью объектов.

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

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

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

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

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

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

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

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

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

Наверное можно было всю эту работу с БД организовать через концепцию ООП, но в Аксапте - этого точно не получилось. Вышло классическая приложение СУБД с приблудой в виде ООП, которая по сути нужна приложению... 'как зайцу стоп-сигнал'(с).
Старый 14.07.2017, 13:42   #58  
Pavel is offline
Pavel
SAP
SAP
 
2,714 / 230 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от macklakov Посмотреть сообщение
Изрядная часть этих изысков результат пересадки ГК из GP в AX. При том что вся логика модулей не рассчитана на работу с такой ГК. Я когда на это смотрю, каждый раз поражаюсь таланту архитекторов и программистов, которые таки заставили подобное решение хоть как-то работать.
Интересно, что же такое пересадили в ГК из GP в АХ, необходимое не ради 'архитектуры', а как часть развития бизнес-приложения... то что модно называть громким словом - РЕШЕНИЕ?!

пс. Чего там так не хватало))))
Старый 14.07.2017, 16:28   #59  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,572 / 507 (20) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от dech Посмотреть сообщение
Я скажу так, цель ООП - в первую очередь облегчить понимание кода, перейти на новый уровень абстракций. Например если проводишь манипуляции не с какой-либо функцией, на входе которой 5-7 (а то и >10) параметров строкового типа, а с методом, часть данных которого уже хранится в экземпляре класса, а другая часть передается в виде одного-двух объектов.
...
Насчет понимания, приведу пример. Есть два класса, которые делают некоторый расчет суммы по оплате немного по-разному.
Любая абстракция усложняет понимание. Любое ООП - запутывает. Процедурное программирование - легче для понимания. Там где достаточно процедурного программирования - должно быть только оно.

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

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

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

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

ERP как набору workflow и на реляционной СУБД - ООП только во вред. Потому как используется только для оverengineering подавляющим большинством программистов.
Старый 14.07.2017, 17:54   #60  
Bobkov is offline
Bobkov
Участник
Аватар для Bobkov
 
230 / 285 (10) ++++++
Регистрация: 30.10.2002
Адрес: Moscow
Цитата:
Сообщение от ax_mct Посмотреть сообщение
То что модуль ERP должен быть самодостаточным доменом - это на самом деле золотая идея. Те же микро-сервисы на уровне модулей ERP.
Мне кажется, важнее всего не то, что модуль можно вынуть и заменить на что-то, а то что этот модуль вообще выделен как сущность обособленная, то есть имеющая минимум связей с другими модулями. Не только связей по коду, но и связей по данным. Эти связи должны быть максимально четко специфицированы и их должно быть невозможно случайно нарушить. Если выделить в системе такой модуль, то оказывается, что сложность его познания и развития упала на порядок, что собственно и требуется. Можно ли использовать для реализации такой модульности ООП? Наверное, можно в какой-то части. Я бы наверное взял из ООП принцип инкапсуляции и постарался им ограничиться.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Похоже "Лучший по ..." превращается в "филькину грамоту". Что сделать, чтобы не превращалась? mazzy Обсуждение форума 47 18.10.2013 21:21
"Эти ваши интернеты": Прянишников "нокаутировал" Плющева mazzy Курилка 2 20.10.2011 10:56
Call of Duty: "No Russian" или "Ни слова по-русски" EVGL Курилка 30 01.02.2010 11:28
"Выделить все" и "Отменить выделение всех" Gustav Курилка 5 18.09.2009 14:40
"Счастливый кроха" в фильме "Бригада" Gustav Детская 14 01.06.2007 11:53
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:52.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.