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

[ax_mct]

Цитата:

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

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

Одна шляпа - это программизм. Если бы и таблицы и код были отдельны и независимы всем было бы лучше. Кроме программистов которым больно смотреть на дублирование кода и данных.

Цитата:

Сообщение от Raven Melancholic

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

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

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

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

[Raven Melancholic]

Цитата:

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

Программистский подход - искать общее, объединять.

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

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

Именно что программистский учет не должен отражать то чего нет в реальности. Дублирование кода - наименьшее зло.

Цитата:

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