QueryBuilder и AR в отдельном пакете?

Не относящиеся к фреймворку и программированию вопросы
Аватара пользователя
ElisDN
Сообщения: 5355
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.17, 21:21

skynin писал(а):
2019.08.17, 17:10
только объектом можно сделать как "существительное" так и "глагол"
Ну приведите пример объекта-глагола.

Глагол – это обычно процедура или функция, а не объект.
skynin писал(а):
2019.08.17, 17:10
ООП не навязывает способ декомпозиции - как при моделировании, так и при написании кода
Кубик рубика можно описать как объект с поведением и состоянием, а можно описать клеточки и стороны и правила их взаимодействия, чтобы сэмулировать "кубик рубика"
Как удобнее - общего правила нет.
Но точно, еще раз - сами ООП не обязывают описывать "кубик рубика" как объект, ни на уровне модели, ни на уровне кода
Да, это будет система клеточек и сторон с правилами взаимодействия (поведение системы с бизнес-логикой вращения). Но нам где-то нужно будет хранить текущее состояние этой системы. Карту позиций и углов каждой клетки. Её можно хранить или в отдельной переменной и менять его процедурно или функционально, или вместе с правилами объединить в объект "кубик".
skynin писал(а):
2019.08.17, 17:10
не надо телепатировать. тем более в таком ключе - вы кретин что-ля?
Это не телепатирование, а ответ на ваш перл, что в Go нет классов и объектов и нет ни одной ОО строки.
skynin писал(а):
2019.08.17, 17:10
объект(в ЯП) и сущность(домена) - не синонимы никак.
Но у того и у того есть поведение и инкапсуляция. Так что в этом плане разницы нет.
skynin писал(а):
2019.08.17, 17:10
Я же видел обычно как реальные проблемы приводили в проектах к дрейфу от "просто доставания и сохранения доменных объектов" в сторону выделения сервисов, то есть выноса управления состоянием из доменных объектов.
Тогда называйте, какие это проблемы, а не просто философствуйте. И связаны ли они с неверным разделением контекстов.
skynin писал(а):
2019.08.17, 17:10
и, как уже писал, вообще перенос управлением состоянием, в сторону хранимых процедур на сервере БД.
Всего лишь перенос логики из внешнего ЯП проекта во внутренний ЯП базы данных. Для снижения накладных расходов на мэппинг и повышения консистентности в пределах одной базы. И даже с этим можно работать объектно в виде DB Speaking объектов с инкапсулированной логикой.
skynin писал(а):
2019.08.17, 17:10
наоборот - как-то не припомню.
Могу подсказать. Это все проекты, решившие стать микросервисными.
skynin писал(а):
2019.08.17, 17:10
как-то не хватает фантазии представить что - выгоднее перенести управление состоянием доменных объектов из ХП или сервисов в сами эти объекты. на старте то так и было, что же потом происходит?
На старте было монолитом на хранимках и триггерах. Что же потом происходит? Происходит разделение на подпроекты с отдельными базами. Это ведёт к отказу от предыдущих хранимок и нативной консистентности, так как в распределённой системе они абсолютно бесполезны. И логика из многих хранимок переходит в код.
skynin писал(а):
2019.08.17, 17:10
даже у вас - если доменный объект весь такой самостоятельный - то зачем же ему ORM?
Чтобы сохранять весь такой самостоятельный объект в персистентное хранилище.

skynin
Сообщения: 186
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.17, 23:22

-- Ну приведите пример объекта-глагола.
сервисы, дата провайдеры, и т.п. инфраструктурные сущности - с состоянием

То есть такие объекты которые являются моделями - действий в предметной области, а не объектов-субъеков.

и состоянием у таких объектов является например степень завершенности действия.

-- Но нам где-то нужно будет хранить текущее состояние этой системы.
где-то конечно нужно.
вопрос же в КАК мы будем хранить.

-- что в Go нет классов и объектов и нет ни одной ОО строки.
там имелось ввиду что для фантазирования уже есть язык, который похож на тот мифический

-- Тогда называйте, какие это проблемы
почитайте критику ООП функциональщиками за последние лет 15
долго пересказывать, в чем правда в тезисе "Почему ООП провалилось?"
частично затронул выше в постах.

и критику ORMов - спецами в БД. Навскидку, нагуглите статью "Вьетнам компьютерной науки"

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

не вам лично конечно. это распространенная хворь среди ООП теоретиков.
У Гради Буча, в его книге она тоже заметна :)

А философия то предлагает и другие подходы, как выше уже упомянул:
моделирование не в объект-субъектной парадигме, а в - процессной.

Причем интуитивно, сталкиваясь с недостатками о-с моделирования и приходят к процессному моделированию.

-- Это все проекты, решившие стать микросервисными.
микросервисы-монолит - вообще не имеют никакого отношения к поднимаемым вопросам :)

это вообще о другом. даже не о программировании, а о "схемотехнике".

-- Чтобы сохранять весь такой самостоятельный объект в персистентное хранилище.
то есть он - не самостоятельный, раз не умеет ни сохранить себя - сам, ни прочитаться - сам :)

-- На старте было монолитом на хранимках и триггерах. Что же потом происходит? Происходит разделение на подпроекты с отдельными базами.
И так бывает, да
Но тогда точно вся жирнота reach model исчезает. И проектировать уже чаще приходится в терминах сервисов обрабатывающих сырые данные, а не в терминах "самостоятельных объектов".
Неврубающийся не может опознать врубающегося.

skynin
Сообщения: 186
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.17, 23:57

да, и упоминали Алана Кея, и акторы, и Эрланг

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

и чем крупнее, сложнее система, тем объекты в ней будут все более "атомарными", удаленными от красивого такого ОО проектирования.

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

anton_z
Сообщения: 418
Зарегистрирован: 2017.01.15, 15:01

Re: QueryBuilder и AR в отдельном пакете?

Сообщение anton_z » 2019.08.18, 02:12

Кстати, раз пошел такой разговор, про разницу между DDD и ООП говорили в этой теме.

Аватара пользователя
ElisDN
Сообщения: 5355
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.18, 09:54

skynin писал(а):
2019.08.17, 23:22
сервисы, дата провайдеры, и т.п. инфраструктурные сущности - с состоянием
То есть такие объекты которые являются моделями - действий в предметной области, а не объектов-субъеков.
и состоянием у таких объектов является например степень завершенности действия.
Без состояния они просто представляют из себя процедуры. С состоянием (что бывает весьма редко) такие объекты-процессы уже нужно идентифицировать и сохранять как сущности.

Но в любом случае эти сервисы, процесс-менеджеры или саги в ООП работают как тонкий контроллер, который только управляет процессом, а всю деятельность делегирует методам сущности.
skynin писал(а):
2019.08.17, 23:22
где-то конечно нужно.
вопрос же в КАК мы будем хранить.
Про это и была речь. Если состояние хранить в отдельной переменной и менять его процедурно или функционально, то это будет ПП или ФП. Если карту вместе с правилами объединить в объект "кубик" и поворачивать его методами, то это будет ООП:

Код: Выделить всё

// ПП
$state = generateRubik();
spinRubik(&$state, $side, $direction);
print_r($state);

// ФП
$state = generateRubik();
$state = spinRubik($state, $side, $direction);
print_r($state);

// ООП
$rubik = new Rubik();
$rubic->spin($side, $direction);
print_r($rubik->getState());
Если поведение инкапсулировано с состоянием в объекте, то это ООП. Если разделено на стейт и поведение, то ПП или ФП.
skynin писал(а):
2019.08.17, 23:22
там имелось ввиду что для фантазирования уже есть язык, который похож на тот мифический
А оказалось, что не похож.
skynin писал(а):
2019.08.17, 23:22
почитайте критику ООП функциональщиками за последние лет 15
долго пересказывать, в чем правда в тезисе "Почему ООП провалилось?"
частично затронул выше в постах.
На тему "ООП vs ФП" прочитайте и этот труд. Проблемы начинаются всегда при использовании чего-то не по назначению.
skynin писал(а):
2019.08.17, 23:22
и критику ORMов - спецами в БД. Навскидку, нагуглите статью "Вьетнам компьютерной науки"
Как уже говорил, если вся логика в БД, то используйте средства БД. Если логика в объектах, то используйте ORM. Либо гибрид в виде ActiveRecord или любого DB Speaking object от Егора.
skynin писал(а):
2019.08.17, 23:22
микросервисы-монолит - вообще не имеют никакого отношения к поднимаемым вопросам :)
это вообще о другом. даже не о программировании, а о "схемотехнике".
Хранимки тоже никакого отношения не имеют к вопросам о сервисах в ООП. А микросервисы - как раз пример, когда логику из многих хранимок переносят в код. И там выбор хранилищ разработчиками адекватнее, чем в монолитах.
skynin писал(а):
2019.08.17, 23:22
то есть он - не самостоятельный, раз не умеет ни сохранить себя - сам, ни прочитаться - сам :)
Он оперирует своими данными и делает своё дело. Ему на своём уровне не интересно, куда его захочет или не захочет сохранить и откуда достать вышележащее приложение.
skynin писал(а):
2019.08.17, 23:57
так вот, если даже брать ООП от Кея, то оно не обязывает моделировать доменные сущности одним объектом, ни наследованием, ни композицией...
Оно обязывет моделировать всё объектами с инкапсуляцией.
skynin писал(а):
2019.08.17, 23:57
в итоге - система вполне "понимает" что такое доменная сущность Пользователь, но объекта такого вы в ней не найдете.
Не найдём как раз потому, что никакой вами придуманной "доменной сущности Пользователь" вообще нет и быть не должно.
skynin писал(а):
2019.08.17, 23:22
Но тогда точно вся жирнота reach model исчезает. И проектировать уже чаще приходится в терминах сервисов обрабатывающих сырые данные, а не в терминах "самостоятельных объектов".
Не умеете программировать без сервисов?
Не умеете делать reach model нежирной?
Не умеете не использовать ORM для листингов?
Не знаете, когда использовать ФП, а когда ООП?
Не согласны с определением, что ООП - это про инкапсуляцию состояния и поведения?

Спор ваш именно со мной о чём?

skynin
Сообщения: 186
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.18, 14:17

-- Спор ваш именно со мной о чём?
Да так, интересно было поинтересоваться - преподаватель-теоретик или практик?

-- Не умеете ...
Я то как раз всяко умею. И так, и эдак :)
Но вы и правда мните себя познавшим суть :)
Может проф деформация преподавателя... судя по поверхности труда "ООП vs ФП"

В любом случае спасибо, было интересно :)
Неврубающийся не может опознать врубающегося.

Аватара пользователя
ElisDN
Сообщения: 5355
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.18, 20:30

skynin писал(а):
2019.08.18, 14:17
Я то как раз всяко умею. И так, и эдак :)
Умели бы – смогли бы отличить объект от процедуры.
skynin писал(а):
2019.08.18, 14:17
В любом случае спасибо, было интересно :)
Плохому танцору объекты мешают. Вердикт понятен.

Ну и удачи с джунами. Втирайте им свою мудрость про Go без объектов и дальше.

skynin
Сообщения: 186
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.19, 08:07

ElisDN писал(а):
2019.08.18, 20:30
Умели бы – смогли бы отличить объект от процедуры.
интересно, на какую позицию вы меня не взяли, что я потерял от этой оценки :)
ну чтоб локти кусать.
ElisDN писал(а):
2019.08.18, 20:30
Плохому танцору объекты мешают
Скорее "Когда у тебя в руках молоток, все задачи кажутся гвоздями"
ElisDN писал(а):
2019.08.18, 20:30
Ну и удачи с джунами. Втирайте им свою мудрость про Go без объектов и дальше.
странное пожелание, это преподователю нужна эта удача, чтобы втирать и зарабатывать этим деньги.
у меня ж забота не готовить разработчиков к собеседованию, а повышать их эффективность.
Неврубающийся не может опознать врубающегося.

Аватара пользователя
ElisDN
Сообщения: 5355
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.19, 12:49

skynin писал(а):
2019.08.19, 08:07
интересно, на какую позицию вы меня не взяли, что я потерял от этой оценки :)
Любую, кроме локальной исполнительской. Аккуратный человек аккуратен во всём. И наоборот. Если программист не разбирается в терминологии программирования, то и в доменной терминологии будет косячить. А если у него в голове каша вроде "в Go нет объектов", "Doctrine чудит с построением запросов" и "ФП-шники разоблачили ООП", то сложно представить, что из него ещё всплывёт через неделю и какое он на основе этого примет архитектурное решение.
skynin писал(а):
2019.08.19, 08:07
Скорее "Когда у тебя в руках молоток, все задачи кажутся гвоздями"
Да, про это и говорю, что отношение к связанности и выбор хранилищ у разработчиков микросервисов адекватнее запросам, чем у хранимопроцедурщиков в монолитах.

skynin
Сообщения: 186
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.19, 14:01

ElisDN писал(а):
2019.08.19, 12:49
Любую, кроме локальной исполнительской
странно что я давно и не искал такой работы.
а берут, на ту где я провожу собеседования разработчиков.
и сейчас вот же странно, и архитектор и тех лид... еще и работа с двумя субподрядчиками на мне.

но вам конечно видней, как несчастны мои работодатели последних лет 10 так точно.

А может все же - вы нателепатировали себе не то, не? ;)
но думаю что не приходило вам такое на ум.

перефразируя ваше про аккуратность
упоротый в одном - упорот во всем остальном :)

но, было интересно переоткрыть этот факт:
Если кто-то кого-то считает кретином - то один из них точно кретин!
Неврубающийся не может опознать врубающегося.

Аватара пользователя
ElisDN
Сообщения: 5355
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение ElisDN » 2019.08.19, 14:58

skynin писал(а):
2019.08.19, 14:01
а берут, на ту где я провожу собеседования разработчиков.
и сейчас вот же странно, и архитектор и тех лид... еще и работа с двумя субподрядчиками на мне.
но вам конечно видней, как несчастны мои работодатели последних лет 10 так точно.
Да хоть практик-техлид-битриксоид с 50-летним стажем и сотнями довольных клиентов.
Кто у джуна спросит про Go без объектов - без разницы.
skynin писал(а):
2019.08.17, 17:10
А может все же - вы нателепатировали себе не то, не? ;)
Не. Просто цитаты определений скинул. Вам они почему-то не понравились и вы ко мне прикопались.
skynin писал(а):
2019.08.17, 17:10
вы кретин что-ля?
skynin писал(а):
2019.08.19, 14:01
Если кто-то кого-то считает кретином - то один из них точно кретин!
Ну вот и подтверждение. В медицинской терминологии разбираетесь также "успешно", как и в девелоперской. Как раз об этом я и говорил.

skynin
Сообщения: 186
Зарегистрирован: 2017.12.12, 10:09

Re: QueryBuilder и AR в отдельном пакете?

Сообщение skynin » 2019.08.19, 15:34

ElisDN писал(а):
2019.08.19, 14:58
Не. Просто цитаты определений скинул. Вам они почему-то не понравились и вы ко мне прикопались.
обязанность джуна - зазубрить.
а вот уже если мидл - то понимать.

перепостинг википедии - не аргумент в понимании :)
ElisDN писал(а):
2019.08.19, 14:58
и вы ко мне прикопались.
я же сказал, интересно было.
с преподами в реале давно не общался :)

обычный то круг - программисты. которые говорят казенным языком, из википедий, только на собеседованиях.
и то, если их принуждают к этому.
а во время работы на крайне неакуратном сленге. еще и специфическом для проекта, если проект большой и долгий.
"препод" бы уволил всех, однозначно! :D
вместе с отвечающими за архитектурные решения, которые сплошь компромиссы.

и действительно было интересно, на какую работу меня не взяли то :)

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

буду знать, на джуна все, не возьмут! :D

впрочем, как говорится выпускник ВУЗа обычно уже не сможет поступить в него же :)
ElisDN писал(а):
2019.08.19, 14:58
В медицинской терминологии разбираетесь также "успешно", как и в девелоперской.
да, да, вы именно того и встретили в моем лице :D

особенно интересно что вы про Go от меня услышали. я так и не придумал как пояснить что я имел ввиду :)
И про мои сложности с объектами, которые еще в 90ых мы эмулировали на plain С в продакшн коде.

ну и еще о сложных проектах, о которых у вас такие смутные впечатления

за анализ и проектирование доменной области на сложных проектах отвечает очень маленькое количество людей

никто на сложном проекте не даст выбирать ни парадигму, ни декомпозицию домена рядовому программисту.

уже в команде больше 5ти человек так.

и польза от изучения теории, или вашего педагогического кода для программиста в том, что ему легче будет объяснить в реальном проекте - вот теория, а у нас вот такие от нее отклонения

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

ну и было интересно - преподающий то это понимает?
а преподающий разжаловал до трейни наверное :D

ну ок, дело такое :)
Неврубающийся не может опознать врубающегося.

anton_z
Сообщения: 418
Зарегистрирован: 2017.01.15, 15:01

Re: QueryBuilder и AR в отдельном пакете?

Сообщение anton_z » 2019.08.19, 16:17

ElisDN писал(а):
2019.08.18, 09:54

Он оперирует своими данными и делает своё дело. Ему на своём уровне не интересно, куда его захочет или не захочет сохранить и откуда достать вышележащее приложение.
ElisDN писал(а):
2019.08.18, 09:54
skynin писал(а):
2019.08.17, 23:57
так вот, если даже брать ООП от Кея, то оно не обязывает моделировать доменные сущности одним объектом, ни наследованием, ни композицией...
Оно обязывет моделировать всё объектами с инкапсуляцией.
Вот именно, с инкапсуляцией. Я думаю в этом есть главное идеологическое противоречие DataMapper ORM - нарушение инкапсуляции, основы ООП. Без оного DataMapper не достанет данные из объекта.

Аватара пользователя
samdark
Администратор
Сообщения: 9128
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: QueryBuilder и AR в отдельном пакете?

Сообщение samdark » 2019.08.19, 18:52

Утащил холивар в "обо всём" чтобы не отвлекал от тем по разработке Yii 3...

// Уровень аргументации сторон неплохой. Растём :)

Ответить