|
28.06.2017, 14:38 | #1 |
Banned
|
То что модуль ERP должен быть самодостаточным доменом - это на самом деле золотая идея. Те же микро-сервисы но уровне модулей ERP.
ООП без границ модулей - создало неподьемный монолит. Цитата:
ООП - это хороший инструмент, но ООП для бизнес-логики ERP приносит намного больше вреда чем пользы. Поэтому код по несколько тысяч строк - меньшее из зол. |
|
13.07.2017, 21:17 | #2 |
Участник
|
Цитата:
А почему? Могу сказать, что корень всего зла кроется в сжатых сроках, в рамках которых необходимо выполнить задачу. Чаще всего самый дебильный код получается тогда, когда ты с ошалевшими глазами стучишь по клавиатуре, и нет у тебя времени на рефакторинг своего кода.
__________________
// no comments |
|
13.07.2017, 21:43 | #3 |
Участник
|
Цитата:
Сообщение от dech
Полный бред. Вы соглашаетесь, что ООП - это хорошо и тут же пишете, что это плохо. С чего бы самому ООП быть злом? Может быть зло в тех, кто не умеет применять ООП? Я готов поспорить, в MS полно таких ребят. В АХ2012 появилось очень много "неправильной" архитектуры.
А почему? Могу сказать, что корень всего зла кроется в сжатых сроках, в рамках которых необходимо выполнить задачу. Чаще всего самый дебильный код получается тогда, когда ты с ошалевшими глазами стучишь по клавиатуре, и нет у тебя времени на рефакторинг своего кода. Не то чтобы я с вами не был согласен |
|
|
За это сообщение автора поблагодарили: Logger (1). |
14.07.2017, 02:28 | #4 |
NavAx
|
Цитата:
Изрядная часть этих изысков результат пересадки ГК из GP в AX. При том что вся логика модулей не рассчитана на работу с такой ГК. Я когда на это смотрю, каждый раз поражаюсь таланту архитекторов и программистов, которые таки заставили подобное решение хоть как-то работать. Хотя, к банковскому модулю вопросы есть, конечно. Перемудрили на ровном месте.
__________________
Isn't it nice when things just work? |
|
14.07.2017, 13:42 | #5 |
SAP
|
Цитата:
пс. Чего там так не хватало)))) |
|
17.07.2017, 02:45 | #6 |
NavAx
|
Можно предположить что цель всех этих телодвижений была в том, чтобы легче было перетаскивать GP клиентов на AX, ибо в US именно GP имела самый большой рынок из линейки Dynamics. По факту, конечно же, стало гораздо сложнее. Бухгалтера довольно безболезнено пересаживались с GP на 2009, ибо сразу понятно что это совсем другая система, со своей логикой. Из-за 2012-й иногда половина отдела увольняется. Т.к. с виду вроде как напоминает GP, но ничего не получается сделать привычным способом. С их точки зрения это не новая продвинутая система в которой надо разбираться чтобы идти в ногу со временим, а это какая-то ужасно изуродованная GP, в которой ничего не работает как надо.
__________________
Isn't it nice when things just work? |
|
13.07.2017, 22:33 | #7 |
Banned
|
Цитата:
Бизнес это живой функционирующий организм который сегодня ходит на ногах, а завтра на руках. SOP, SOA - здесь намного более уместнее чем OOP. Грубо SOA это функция в которую мы передаем объекты, бизнес-процесс отделим от данных. В то время как OOP это обьединение данных и функций как некое моделирование реальности. По факту с OOP мы натягиваем зад на глаз только ради парадигмы, а не как отражение реальности. При том что результат действия нашего кода - выполнение той или иной функции обработки. ООП это помеха быстрому и надежному программированию бизнес-логики. ООП хорошо только для платформы как единственного и технического фрэймворка. ООП это как короткая юбка на темной улице. Если бы Аксапта не поддерживала ООП то она былв бы сейчас живой. Последний раз редактировалось ax_mct; 13.07.2017 в 22:36. |
|
14.07.2017, 12:28 | #8 |
Участник
|
Цитата:
Цитата:
Сообщение от ax_mct
ERP как системе операций не нужно быть совокупностью объектов.
Бизнес это живой функционирующий организм который сегодня ходит на ногах, а завтра на руках. SOP, SOA - здесь намного более уместнее чем OOP. Грубо SOA это функция в которую мы передаем объекты, бизнес-процесс отделим от данных. В то время как OOP это обьединение данных и функций как некое моделирование реальности. По факту с OOP мы натягиваем зад на глаз только ради парадигмы, а не как отражение реальности. При том что результат действия нашего кода - выполнение той или иной функции обработки. ООП это помеха быстрому и надежному программированию бизнес-логики. ООП хорошо только для платформы как единственного и технического фрэймворка. ООП это как короткая юбка на темной улице. Если бы Аксапта не поддерживала ООП то она былв бы сейчас живой. Я не понимаю, что вы хотите получить, отделяя бизнес-процесс от данных? швейцарский нож, который может и секатором работать, и бензопилой?))) Каждый объект данных требует своей собственной обработки. Вам не уйти от ООП, как бы вам этого ни хотелось. Насчет понимания, приведу пример. Есть два класса, которые делают некоторый расчет суммы по оплате немного по-разному. Вроде всё круто, всего 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 | #9 |
SAP
|
Цитата:
Сообщение от ax_mct
ERP как системе операций не нужно быть совокупностью объектов.
Бизнес это живой функционирующий организм который сегодня ходит на ногах, а завтра на руках. SOP, SOA - здесь намного более уместнее чем OOP. Грубо SOA это функция в которую мы передаем объекты, бизнес-процесс отделим от данных. В то время как OOP это обьединение данных и функций как некое моделирование реальности. По факту с OOP мы натягиваем зад на глаз только ради парадигмы, а не как отражение реальности. При том что результат действия нашего кода - выполнение той или иной функции обработки. ООП это помеха быстрому и надежному программированию бизнес-логики. ООП хорошо только для платформы как единственного и технического фрэймворка. ООП это как короткая юбка на темной улице. Если бы Аксапта не поддерживала ООП то она былв бы сейчас живой. Здесь совершенно конкретное направление приложений - СУБД. Те суть-данные организованы в записи таблиц, а не есть содержание объектов (экзепляров классов). Методы обработки данных - это суть БИЗНЕС-ПРИЛОЖЕНИЯ, те бизнес-логика, реализованная с помощью классических элементов СУБД(процедуры, функции, триггеры, списки, макросы, формы, отчеты, запросы, меню и тд). Аналогом полиморфизма в ООП служили слои, те когда разработчик менял менял не сам объект, а создавал актуальную для приложения его копию. Еще есть ЯДРО, которое может быть написано на чем угодно, под любую среду и интерфейс. Ядро должно использовать бизнес-логику как некую библиотеку сущностей, а само решать все технологические аспекты по отношению к аппаратному и программному обеспечению, на котором работает приложение. В плане инкапсуляции данных, которая по сути обеспечивает сохранность данных и устойчивость работы приложения... все было в порядке и без ООП. А именно текущие переменные объявлялись и использовались в методах (процедуры, запросы, макросы, триггеры, меню, формы, отчеты,...), а все так сказать 'глобальные' внешние переменные оказались организованы в записи таблиц БД. Наверное можно было всю эту работу с БД организовать через концепцию ООП, но в Аксапте - этого точно не получилось. Вышло классическая приложение СУБД с приблудой в виде ООП, которая по сути нужна приложению... 'как зайцу стоп-сигнал'(с). |
|
14.07.2017, 16:28 | #10 |
Banned
|
Цитата:
Сообщение от dech
Я скажу так, цель ООП - в первую очередь облегчить понимание кода, перейти на новый уровень абстракций. Например если проводишь манипуляции не с какой-либо функцией, на входе которой 5-7 (а то и >10) параметров строкового типа, а с методом, часть данных которого уже хранится в экземпляре класса, а другая часть передается в виде одного-двух объектов.
... Насчет понимания, приведу пример. Есть два класса, которые делают некоторый расчет суммы по оплате немного по-разному. В приведенном примере нам надо сделать подсчет, а не моделировать поведение обьекта Site. Объектное мышление здесь только вредит. VB6 или даже VBA здесь достаточно. Скрывать в инкапсуляции здесь нечего и незачем. Я не говорю что абстракции или ООП это плохо. Я говорю о том что это надо применять только там где без этого не обойтись. Путаница в приведенном примере только из-за использования ООП там где просто нужны две тупые функции. Цитата:
Сообщение от dech
Я не понимаю, что вы хотите получить, отделяя бизнес-процесс от данных? швейцарский нож, который может и секатором работать, и бензопилой?))) Каждый объект данных требует своей собственной обработки. Вам не уйти от ООП, как бы вам этого ни хотелось.
... Но именно protected обеспечивает нормальную инкапсуляцию, пряча детали внутрь класса. Pavel 200 раз прав про уместность. Цитата:
Сообщение от Pavel
Здесь совершенно конкретное направление приложений - СУБД. Те суть-данные организованы в записи таблиц, а не есть содержание объектов (экзепляров классов).
Методы обработки данных - это суть БИЗНЕС-ПРИЛОЖЕНИЯ, те бизнес-логика, реализованная с помощью классических элементов СУБД(процедуры, функции, триггеры, списки, макросы, формы, отчеты, запросы, меню и тд). ... В плане инкапсуляции данных, которая по сути обеспечивает сохранность данных и устойчивость работы приложения... все было в порядке и без ООП. А именно текущие переменные объявлялись и использовались в методах (процедуры, запросы, макросы, триггеры, меню, формы, отчеты,...), а все так сказать 'глобальные' внешние переменные оказались организованы в записи таблиц БД. Наверное можно было всю эту работу с БД организовать через концепцию ООП, но в Аксапте - этого точно не получилось. Вышло классическая приложение СУБД с приблудой в виде ООП, которая по сути нужна приложению... 'как зайцу стоп-сигнал'(с). ERP как набору workflow и на реляционной СУБД - ООП только во вред. Потому как используется только для оverengineering подавляющим большинством программистов. |
|
14.07.2017, 17:54 | #11 |
Участник
|
Мне кажется, важнее всего не то, что модуль можно вынуть и заменить на что-то, а то что этот модуль вообще выделен как сущность обособленная, то есть имеющая минимум связей с другими модулями. Не только связей по коду, но и связей по данным. Эти связи должны быть максимально четко специфицированы и их должно быть невозможно случайно нарушить. Если выделить в системе такой модуль, то оказывается, что сложность его познания и развития упала на порядок, что собственно и требуется. Можно ли использовать для реализации такой модульности ООП? Наверное, можно в какой-то части. Я бы наверное взял из ООП принцип инкапсуляции и постарался им ограничиться.
|
|
14.07.2017, 19:15 | #12 |
SAP
|
Цитата:
Сообщение от Bobkov
Мне кажется, важнее всего не то, что модуль можно вынуть и заменить на что-то, а то что этот модуль вообще выделен как сущность обособленная, то есть имеющая минимум связей с другими модулями. Не только связей по коду, но и связей по данным. Эти связи должны быть максимально четко специфицированы и их должно быть невозможно случайно нарушить.
Разбить модули на независимые сервисы можно, но разделение данных нарушит нормализацию, вместо одной БД возникнет столько, сколько сервисов. Тогда возникнут новые проблемы... не менее интересные (кто занимался синхронизацией и репликацией распределенных данных, тот сталкивался). |
|
14.07.2017, 20:31 | #13 |
Banned
|
Цитата:
Сообщение от Bobkov
Мне кажется, важнее всего не то, что модуль можно вынуть и заменить на что-то, а то что этот модуль вообще выделен как сущность обособленная, то есть имеющая минимум связей с другими модулями. Не только связей по коду, но и связей по данным. Эти связи должны быть максимально четко специфицированы и их должно быть невозможно случайно нарушить. Если выделить в системе такой модуль, то оказывается, что сложность его познания и развития упала на порядок, что собственно и требуется. Можно ли использовать для реализации такой модульности ООП? Наверное, можно в какой-то части. Я бы наверное взял из ООП принцип инкапсуляции и постарался им ограничиться.
Но нам скажут что "одним из методов написания модульных программ является объектно-ориентированное программирование. ООП обеспечивает высокую степень модульности благодаря таким свойствам, как инкапсуляция, полиморфизм и позднее связывание." В то время как ООП нельзя давать в руки адептов это религии в принципе, так как они сокрушат все стенки в доме просто потому что им так лучше видно. Проткнут насквозь все что можно проткнуть. Поэтому те люди что используют T-SQL для бизнес-логики - они гениальны. Потому как программисты больные на голову - им может не хватать слоев абстракции |
|
|
|