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

[belugin]

Цитата:

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

в теории конечно да.
но на практике получаются бесконечные *Adapter, *Handler, *Helper, *Util и прочие расширители.

*Adapter - чем плох? Название говорящее.
*Handler - это действительно непонятно.
*Helper, *Util - лучше класть в тот класс, в котором, собственно, предмет обработки, но если класс чужой а твои методы для него очень специфичны либо это не класс, а интерфейс, то чем плохо положить в *Util? Только надо выбрать один из этьи суффиксов, что в MS не сделано, к сожалению.

Цитата:

тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных...

Печать тоже не печатает, а иногда выводит для предварительного просмотра. Возможно стоило назвать Output, например.

Цитата:

а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию...

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

В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation теперь есть API - то есть если надо его встроить в свой процесс, можно взять и вызвать метод, заполнив контракт, а не вытягивать наружу параметры модифицируя существующий класс

[mazzy]

Цитата:

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

В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation...

видишь ли... никто с этим и не спорит.
но ты совершенно правильно заметил, что только у "построенного с помощью SysOperation". а у остальных, по твоему мнению, нет такой возможности.

в результате у разработчика не один "плохой" набор RunBase
а два совершенно разных.
в результате нужно не только знать оба, но и знать как заставить их работать совместно.

с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась.
а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности.

и так во многих местах аксапты за редким исключением типа (subledger, dimension).
вводятся новые инструменты-фреймворки. пусть они все замечательные.
но старые то не выводятся.

[belugin]

Цитата:

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

видишь ли... никто с этим и не спорит.
но ты совершенно правильно заметил, что только у "построенного с помощью SysOperation". а у остальных, по твоему мнению, нет такой возможности.

Она не гарантируется. Реально никто не заморачивается тем, чтобы сделать API на все.

Цитата:

в результате у разработчика не один "плохой" набор RunBase
а два совершенно разных.
в результате нужно не только знать оба, но и знать как заставить их работать совместно.

Надо знать оба, да. Что такое "знать как их заставить работать совместно"?

В случае RunBase нет почти никакого общего способа заставить работать два RunBase вместе:

- Как использовать бизнеслогику одного из другого надо разбираться с каждым классом (у SysOP есть API который называется стандартно и представляет просто метод с параметром)

- UI совместно не используешь (несколько контрактов SysOP можно скомбинировать в один диалог)

- Только pack можно использовать из другого pack (с runbase надо разбираться - они паковку не вынесли отдельно)

Цитата:

с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась.
а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности.

У какого-то количества классов уменьшилась - параметры, UI и бизнеслогика лежат в стандартных местах и их можно использовать отдельно

Цитата:

и так во многих местах аксапты за редким исключением типа (subledger, dimension).
вводятся новые инструменты-фреймворки. пусть они все замечательные.
но старые то не выводятся.

Мне кажется для живой системы это нормально - не все переводится единомоментно - это постепенный процесс, python 2.5 -> 2.6 -> 3.0 я уже упоминал, в SAP говорят про три механизма для всего: то, что было давно и оставлено для совместимости, то, что используют все сейчас, то, что новое клёвое, но пока мало кто использует.

[mazzy]

Цитата:

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

Реально никто не заморачивается тем, чтобы сделать API на все.

1. не надо демагогии и слова ВСЕ ))) речь идет о SysOperation, которая должна заменить RunBase.
2. "Реально никто [в МС] не заморачивается" - это и есть причина Оver-engineering с точки зрения остальных разработчиков.

Тут, наверное, мне стоит объяснить остальным участникам,
что фраза Макса "не заморачивается [API]" вовсе не говорит о том, что разработчики в МС не заморачиваются ничем.
В МС самая замороченная процедура приемки кода изо всех что я видел. Поэтому заморачиваться разработчику в МС приходится очень много чем.

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

Цитата:

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

Надо знать оба, да. Что такое "знать как их заставить работать совместно"?

В случае RunBase нет почти никакого общего способа заставить работать два RunBase вместе:

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

Цитата:

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

- Как использовать бизнеслогику одного из другого надо разбираться с каждым классом

вообще говоря, нет. см. MenuFunction.

Цитата:

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

- UI совместно не используешь (несколько контрактов SysOP можно скомбинировать в один диалог)

э-э-э...
можно я не буду дальше комментировать?

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

Цитата:

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

У какого-то количества классов уменьшилась - параметры, UI и бизнеслогика лежат в стандартных местах и их можно использовать отдельно

я предполагаю о чем ты.
но для определенности, можешь привести пример?

Цитата:

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

в SAP говорят про три механизма

Ой, все! вот только не надо как 1Сники валить на другую систему. Типа "у нас гавно, а вот там еще хуже".
фиг с ними, с сапами, давай в своей системе разбираться/прибираться.