код соотвествующий схеме
Объекты выступают,
как носители данных, и ссесии как
управляющие этими данными. Это не объектно.
- ООП - объекты прячут от нас данные и работа происходит на более высоком уровне абстракции;
- Процедурное программирование - код управляет непосредственно данными, данные открыты.
Главное
проблема с процедурным программированием - трудно поддерживать такой код. А из Java пытаются
делать C++
Инкапсулировать поведение внутрь объекта и не выдавать данные наружу. Убрать геттеры, перестать делать объект хранилищем данных из которых можно что то достать. Это не глупая корзина с примитивами
Мы должны
доверять объекту, уважать его. Поэтому он должен
сам делать то, что нужно. Мы должны
объединить и данные и функционал. Объект
должен сам решать, что предпринять.
DTO Data Transfer Object -
это не правильно, это антипатерн. Это совершенно
не тестируется
Вы писали
тесты на гибернетйте? Это крайне
сложно - набор пустых дата объектов и
процедуры, от которых ушли 40-30 лет назад
Да, это можно
тестировать интеграционным тестированием - но это уже не
юнит тест, выполняющийся за миллисекунды.
Здесь нет
логики….. что тестировать?
Объекты —
данные, везде, везде, а код — в
процедурах
да конечно
можно поднять на новый уровень и
тестировать, как объект меняющий
пользователя
Интеграционное тестирование - это
тестирование очень большого объекта,
а юнит тестирование - это тестирование
маленького объекта SingleRespPrincip
В гибернейт
мы этого сделать не можем потому что
объекты — структура данных а не реальный
объект
Самая большая
проблема — ORM не делает маппинга, мы все
равно остаемся в реляционной модели,
мы не можем воткнуть NoSQL потому что
модель у нас реляционная.
И DAO тоже не
спасает ситуацию… тем более что он
и не всегда строится (прям лепят во View
если это MVC и на этом все заканчивается -
конечно так делать не надо но люди
делают). Идея разделения на глупые и
сверх-объекты неправильна.
Мы не только DAO должны
любоваться, как красивым и мощным объектом, нам должен нравиться каждый
из объектов.
Решение:
Вносим необходимый метод (например, rename) внутрь объекта. Теперь он
уже не глупый, я прошу,
как бы ты согласился поменять свое имя,
я с ним начинаю общаться уважительно...
он сам отвечает за свое поведение, все
инкапсулировано.
Не 2 объекта…
в разных местах… ssesion в БД , и там еще
где то… а он один отвечает за свое собственное
переименовывание
вот как это
будет выглядить
теперь
этот класс User полностью изолированная
структура, его можно тестировать…
теперь все кто от него зависят не знают
что у него внутри и им это и не надо
jOOQ библиотека отвечает
за драйвер к СУБД. Теперь мы можем спокойно поменять БД
на другу, для этого он и вставлен.
Для каждого
пользователя есть свой объект и с каждым
пользователем мы работаем по своему,
хоть их миллиард.
Да, он делает
запрос к БД, и так делают
и остальные 10 миллиардов объектов… а
вот чтобы это все не рухнуло, мы должны
сделать оптимизацию, завернуть их в
декоратор.
Если у нас
множество совершенно разных запросов,
то мы их не пихаем в один объект мы
используем другой дизайн (декоратор в
декораторе в декораторе) но в любом
случае мы сами принимаем решение, а не
гибернейт или еще кто-то.
Декораторов
много да, но они ничего не знают про ОРМ,
декораторы маленькие понятные в коде, они как
слои их хоть десятки и они занимаются
только одной задачей.
Вы полагаетесь
на поведение объекта, но не знаете каков
он внутри, и в этом идея
инкапсуляции
Вы не знаете
что внутри объекта. И какой он к
вам пришел … логгирует ли себя, прерывает,
с какой БД работает, этих знаний вам не
дается. Вы просто вызываете нужный вам
метод, а дальше что произойдет не ведомо
и это хорошо.
Транзакции - мы не создаем множества транзакций, создаем одну и в нее
включаем несколько разных объектов и в одной
транзакции выполняем все что необходимо.
Есть репозиторий
- патерн, а есть другой (Визитор):
Объект, ты умеешь печатать - хорошо, мы будем
подставлять разные носители, бумагу,
доску с мелом, клавиатуру и т. п. печатай…
Добавим метод
to XML всем объектам, а вот если мне нужен
JSON, то это уже оберка берем XML и
трансформируем в JSON, но сам объект
об этом уже ничего не знает
Критика Егора. Комбинаторный взрыв:когда в объекте было одно поле, а тут нам нужно добавить еще одно... и, если у нас 50 декораторов, у нас 50 изменений
В Hadoop классы
в 3-4 тыс. строк о каком объектном программировании
может идти речь, класс - это 50-70 строк,
но не больше 200 ну еще раза в 2 раза больше на тестирование, а там их тысячи.
Думать нужно не со
стороны БД а со стороны задачи. Вот у нас
данные и мы хотим сделать по ним выборку,
например - найти мужа и жену. Так может
создать объект семья и уже этот объект будет обращаться к базе, а мы дальше
работаем с этим объектом family целиком
MVC — это
вторая большая ошибка в джаве. Но об этом позже.
ООП очень
понятное по сравнению с техническим
(процедурным) кодированием, это на самом деле дешевле.
Итак создаются корневые классы основной логики, а на них уже декораторы, которые делают их умнее, и далее они включаются в еще более крутые объекты
ООП - это
много-много объектов и только одна
строка ран, а процедурное
— это куча строк выполняемых одна за одной.
Комментариев нет:
Отправить комментарий