Показать сообщение отдельно
Старый 14.07.2017, 16:28   #59  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от dech Посмотреть сообщение
Я скажу так, цель ООП - в первую очередь облегчить понимание кода, перейти на новый уровень абстракций. Например если проводишь манипуляции не с какой-либо функцией, на входе которой 5-7 (а то и >10) параметров строкового типа, а с методом, часть данных которого уже хранится в экземпляре класса, а другая часть передается в виде одного-двух объектов.
...
Насчет понимания, приведу пример. Есть два класса, которые делают некоторый расчет суммы по оплате немного по-разному.
Любая абстракция усложняет понимание. Любое ООП - запутывает. Процедурное программирование - легче для понимания. Там где достаточно процедурного программирования - должно быть только оно.

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

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

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

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

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