зачем нужен ООП в управленческих системах

[lev]

Тема выделена из "Создание нового журнала".

Цитата:

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

зы Вообще не понимаю наличия ООП в управленческих системах! Ну, например, семейство классов SalesPurch - нафига они нужны вместе? Зачем их объединили, чтоб потом в поте лица определять что это - салес или же пурч, ёперный балет!

теперь про тему "зачем нужно ООП в управленческих системах"...

Откройте форму (которая создана, кстати, на SYS слое) SysClassWyzard (это для примера), там есть два метода moveSelectedListItems() и moveAllItems(), эти методы отличаются одной строчкой кода:
в методе moveSelectedListItems() это

idx = _sourceList.getNextItem(FormListNext::Selected);

а в методе moveAllItems() это

idx = _sourceList.getNextItem(FormListNext::All);

У меня сразу возникает вопрос, нафига плодить два метода (о будущей поддержке не думали явно, если вдруг надо будет изменять функционал, нужно будет помнить про оба метода), с абсолютно одинаковым кодом, если можно создать один метод moveItems(), у которого кроме всего прочего на входе будет ещё параметр FormListNext, и использовать один метод, просто передавая туда параметр. Было желание потренироваться в наборе определенного кода? Или какие то другие цели?

Хочется услышать мнение на этот счет сотоварищей связанных аксаптой

[S.Kuskov]

По теме (вынесенной в заголовок ветки). Вопрос равносилен примерно такому: "Зачем использовать средства автоматизации труда в лёгкой промышленности?".

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

достоинства ООП:
Масштабируемость. "Управленческие системы", что не должны быть масштабируемыми?
Унификация. Стандартизация интерфейсов взаимодействия элементов системы - для сложных (состоящих из большого числа элементов) систем это обязательная вещь. "Управленческие системы" на ваш взгляд настолько просты, что ООП их только усложняет? Вы это имеете в виду? Тогда вы вероятно путаете причину со следствием. Аксапта сложна не потому что в ней тысячи клаcсов, а наоборот

[lev]

Цитата:

Сообщение от S.Kuskov

достоинства ООП:
Масштабируемость. "Управленческие системы", что не должны быть масштабируемыми?
Унификация. Стандартизация интерфейсов взаимодействия элементов системы - для сложных (состоящих из большого числа элементов) систем это обязательная вещь. "Управленческие системы" на ваш взгляд настолько просты, что ООП их только усложняет? Вы это имеете в виду? Тогда вы вероятно путаете причину со следствием. Аксапта сложна не потому что в ней тысячи клаcсов, а наоборот

Я надеюсь все эти вопросы не ко мне?
потому как я точно такого же мнения как и Вы

А хотелось бы услышать доводы egorych, именно его фраза в теме "Создание нового журнала" и побудила меня создать эту тему

[S.Kuskov]

Цитата:

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

нафига плодить два метода (о будущей поддержке не думали явно, если вдруг надо будет изменять функционал, нужно будет помнить про оба метода), с абсолютно одинаковым кодом, если можно создать один метод moveItems(), у которого кроме всего прочего на входе будет ещё параметр FormListNext, и использовать один метод, просто передавая туда параметр. Было желание потренироваться в наборе определенного кода? Или какие то другие цели?

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

P.S.: To lev. Всё ясно. "Мопед не мой, я просто разместил объяву" (С)

[lev]

Цитата:

Сообщение от S.Kuskov

Следуя вашей логике следовало бы вообще открыть доступ к элементу _sourceList

не очень понял из чего такой вывод? и задал вопрос конкретно по дублированию одного и того же кода, безотносительно функционала.

Цитата:

Сообщение от S.Kuskov

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

я говорю не про класс, а про форму . Как дублирование кода на форме в два разных методах, относится к адаптации класса? Указанные мной методы вызываются только на форме.

Цитата:

Сообщение от S.Kuskov

P.S.: To lev. Всё ясно. "Мопед не мой, я просто разместил объяву" (С)

это я вообще не понял, чем именно вызвана ирония?

З.Ы. если из первого сообщения не понятно, попробую высказать основную мысль, которую в него закладывал.
ООП это гуд, и упрощает написание, чтение и поддержку кода (не зависимо от назначения системы). а в аксапте же, встречаются места где на ООП просто забили
как то так.

[Alexanderis.ua]

Цитата:

Сообщение от S.Kuskov

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

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

[S.Kuskov]

Ах это ещё всё и на форме?! Ну тогда что могу сказать. Писать код на форме вообще не положено Best Practices

Цитата:

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

а в аксапте же, встречаются места где на ООП просто забили
как то так.

На sys слое ещё и не такое встретишь The daily Axapta WTF

[lev]

Цитата:

Сообщение от S.Kuskov

На sys слое ещё и не такое встретишь The daily Axapta WTF

ага, ага... из той же оперы

[kornix]

Цитата:

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

ООП это гуд, и упрощает написание, чтение и поддержку кода (не зависимо от назначения системы). а в аксапте же, встречаются места где на ООП просто забили
как то так.

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

На мой взгляд нужно разумно использовать ООП + структурное программирование.

[egorych]

Оххх! Не буду сейчас писать ничего - ибо некогда - все эти сказочки про масштабируемость, расширяемость уже наелись, спасибо!
Скажите, САП масштабируемая и расширяемая система? Там если есть пресловутое ООП, то оно так далеко, что и не видно! На каждый пример удачного использования (в Аксапте) есть тыщща примеров гемороя - когда добавление 1 поля в табличку (на формочку) влечет ковыряние в тоннах кода!

[_scorp_]

Цитата:

Сообщение от S.Kuskov

Ах это ещё всё и на форме?! Ну тогда что могу сказать. Писать код на форме вообще не положено Best Practices

Мне кажется это слишком категорично. Если прочитать тот самый BP, то там всё сводится к двум причинам:
1. Код на форме всегда выполняется на клиенте.
2. Код на форме нельзя использовать повторно в каком-то другом месте.

И при этом пишется

Цитата:

If you have code in the form, the code should be for making only simple changes to the appearance of the form or to the form’s query. Try to place the code on the form or on the data source.

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

[S.Kuskov]

Это была ирония. Но как говорится, в каждой шутке есть только доля шутки

[BOAL]

По субж. выделенной темы

А еще есть 1С, где даже в 8.2 ООП так и не появилось. А осталось все "объектным" из заранее зашитых объектов.
И после АХ и ее ООП думать по 1Сному оч сложно, хотя и там люди живут и моды модят, извращаясь порой от отсутствия такого понятия как "таблица", заменяя его где на документ\справочник, а где и регистры, засовывая вместо грида в форму на закладку отчет (по регистру с кнопкой "сформировать"), благо там из отчета можно проваливаться в другие формы, где и идет ввод\редактирование.

В Оракле с его Явой вроде все ок с ООП, но переписывание стандартного функционала ведет к тому, что новый код работает не вместо переписанного, а дополнительно к нему, сперва отменяя результат отработки, что для производительности тоже не гут (тут могу ошибаться или сча не так, инфа со слухов, поправьте оракловеды)

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

Потому многие, кто долго возится с системой, когда-нибудь это понимают и перестают слепо преклоняться перед "стандартом" - его делали люди и кто сказал, что они были более квалифицированы, чем мы или архитектурный замысел идеален?
Потому и живут своей жизнью партнерские решения, написанные сбоку от АХ (но на АХ при использовании всех хороших возможностей). Так как написанное сбоку удобнее - его можно реально развивать и эволюционировать (иметь по нему неустаревающую документацию), а не переписывать (переносить с трудом) при каждом обновлении (правда от АХ2012 это тоже не спасет ) .

[Удвой Покуров]

1. В SAP есть ООП, очень даже. Более того, весь новый код проходит своеобразный ревью на ВР, где как раз регламентировано использовании преимуществ ООП подходов.
2. Вопрос в другом: а кому нужно ООП в ERP - системах? Ну, кроме разработчиков?
Одно ООП преимуществ не даст- многие помнят Эталон от Цефея, он по ООП лет на 10 DAX опредил: в 2002 у него уже были наследуемые таблицы. И где теперь Эталон?

[S.Kuskov]

Цитата:

Сообщение от Удвой Покуров

Вопрос в другом: а кому нужно ООП в ERP - системах? Ну, кроме разработчиков?

Сильно . Действительно, а кирпичи нужны только строителям

[Raven Melancholic]

Цитата:

Сообщение от Удвой Покуров

И где теперь Эталон?

На этаж выше от нашего офиса

[Удвой Покуров]

Цитата:

Сообщение от S.Kuskov

Сильно . Действительно, а кирпичи нужны только строителям

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

[gl00mie]

Мимо тазика. Офисы класса А+ не развиваются - их как построили, так они и будут стоять до момента сноса, максимум их перештукатурят и фурнитуру на дверях поменяют. А ERP-системы (и вообще программные системы - если они востребованы заказчиком, а не стали очередным shelfware) развиваются постоянно, и вот тут очень важную роль начинает играть то, поддерживает ли система ООП или, скажем, интеграцию с CLR.
PS. Мне как потребителю тоже на очень многие вещи начхать, но вот производители бытовой техники почему-то упорно навязывают мне HDMI, а конторы, предоставлющие услуги IP TV, зачем-то требуют, чтобы мой телек поддерживал DVB-C, иначе грозятся впарить мне за отдельные деньги ненужную ТВ-приставку с отдельным кондовым пультом вместо моего универсального, к которому я привык.

[Удвой Покуров]

Хм. Вот SAP несколько десятков лет не поддерживал ООП. И что, Вы думаете, он не развивался? не было модификаций? Отраслевых решений? Решений партнеров??

Отсутствие ООП не помешало стать SAP лидирующей системой в мире. Возможно, все-таки не в ООП дело, как Вы считаете?

[S.Kuskov]

Цитата:

Сообщение от Удвой Покуров

Преимущество именно кирпичей для меня отнюдь не очевидно, но и кирпичное пойдет

Цитата:

Сообщение от Удвой Покуров

Возможно, все-таки не в ООП дело, как Вы считаете?

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

Согласитесь, глупо выглядит клиент, который заказывая "офис класса А+" говорит: не хочу что бы стены были из прямоугольных кирпичей - хочу чтобы из квадратных, говорит, что понимает что стены будут оштукатурены и он формы кирпичей никогда не увидит и вообще он в кирпичах не разбирается но почему-то уверен, что именно для "офисов класса А+" прямоугольные кирпичи не подходят.

Цитата:

Сообщение от Удвой Покуров

Хм. Вот SAP несколько десятков лет не поддерживал ООП. И что, Вы думаете, он не развивался? не было модификаций? Отраслевых решений? Решений партнеров??

Отсутствие ООП не помешало стать SAP лидирующей системой в мире

До промышленной революция люди тоже вручную делали удивительные вещи... Это же не значит что средства автоматизации труда никому не нужны.