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

[Pavel]

Цитата:

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

ERP как системе операций не нужно быть совокупностью объектов.

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

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

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

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

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

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

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

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

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

Цитата:

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

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

Абстрагироваться надо не от реальности, а от неуместного ООП.
Pavel 200 раз прав про уместность.

Цитата:

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

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

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

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

ERP как набору workflow и на реляционной СУБД - ООП только во вред. Потому как используется только для оverengineering подавляющим большинством программистов.