Здравствуйте, Enomay, Вы писали:
E>>>я разве писал что доменный объект сделает update в базе? S>>Что он решает где и какой update сделать.
E>вызов update как следствие работы доменной модели, но не на прямую, конечно же.
Это значит что модель предметной области не решает, где и какой update делать? Или решает таки?
S>>Смысл в том, что в анемике поведением не обладают лишь объекты домена, что в общем случае не классифицирует анемик как не ООП.
E>возьмем 10 процедур. 3 структуры. они друг с другом взаимодействуют. все это написано на Object Pascal. Будет ли это ООП?
Ответ на этот вопрос зависит не от количества процедур, структур, и не от языка, на котором выполнено взаимодействие. Построенное определенным образом взаимодействие вполне можно будет квалифицировать как ООП.
В вашем DDD (в вашей трактовке его) кроме объектов домена разве нет других объектов? На каком основании вы полагаете что раз у объектов домена не наблюдается поведение, то вся программа будет состоять из процедур и структур? Или вы так не считаете? К чему тогда пример с Object Pascal-ем?
E>взять хотя бы википедию E>
E>Объект — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов)[1]. Как правило, при рассмотрении объектов выделяется то, что объекты принадлежат одному или нескольким классам, которые в свою очередь определяют поведение (являются моделью) объекта.
Нечего тут брать. Некоторая сущность... обладающая определенным состоянием и поведенеим... Как правило....
А вот по мнению Кея "Все является объектом".
E>я считаю что работа с анемиками в том виде, в котором его тут пропагандируют — это процедурное программирование. если вы считаете иначе, это ваше право. и мне, впрочем, нет никакого до этого дела.
Если вы классифицируете программы только по исполнению модели предметной области — то это ваше право...
E>>>я не видел таких примеров. S>>Я не видел крокодилов. Очевидно, их нет
E>приписываете себе логику блондинки
Я воспользовался вашей логикой. А теперь ей воспользовались снова вы: E>я о них даже не слышал. и пример никто привести не может. вывод напрашивается сам собой.
, сделав вывод из того о чем даже не слышали.
E>>вызов update как следствие работы доменной модели, но не на прямую, конечно же. S>Это значит что модель предметной области не решает, где и какой update делать? Или решает таки?
вызов update — это следствие работы доменной модели.
E>>возьмем 10 процедур. 3 структуры. они друг с другом взаимодействуют. все это написано на Object Pascal. Будет ли это ООП? S>Ответ на этот вопрос зависит не от количества процедур, структур, и не от языка, на котором выполнено взаимодействие. Построенное определенным образом взаимодействие вполне можно будет квалифицировать как ООП.
мне кажется количество как раз не является решающим фактором. 10 классов не делает подход более ООП, чем 2.
а вот взаимодействие, бесспорно. может.
но мы говорим о конкретной реализации — энемичной модели.
а она, реализации, как раз на ООП не особо то и похожа, на мой взгляд.
S>В вашем DDD (в вашей трактовке его) кроме объектов домена разве нет других объектов? На каком основании вы полагаете что раз у объектов домена не наблюдается S>поведение, то вся программа будет состоять из процедур и структур? Или вы так не считаете? К чему тогда пример с Object Pascal-ем?
разве я говорил что других объектов нет? конечно же есть. но мы говорим о ядре, как я понимаю.
но вполне вероятно, если человек использует процедурный подход для реализации бизнес логики, то он придерживается этого стиля и в остальных частях.
E>>взять хотя бы википедию E>>
E>>Объект — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов)[1]. Как правило, при рассмотрении объектов выделяется то, что объекты принадлежат одному или нескольким классам, которые в свою очередь определяют поведение (являются моделью) объекта.
S>Нечего тут брать. Некоторая сущность... обладающая определенным состоянием и поведенеим... Как правило.... S>А вот по мнению Кея "Все является объектом".
у Кея, имхо, правильная трактовка, но дополнения, мне кажется, были введены для разграничения ООП (DDD) от не ООП (анемик)
S>Если вы классифицируете программы только по исполнению модели предметной области — то это ваше право...
не нужно мне приписывать чужого. я не классифицировал программы.
мы говорим о вариантах реализаций. при том беспредметно. весь этот тред, в общем-то, ни о чем.
E>>приписываете себе логику блондинки S>Я воспользовался вашей логикой. А теперь ей воспользовались снова вы: E>>я о них даже не слышал. и пример никто привести не может. вывод напрашивается сам собой. S>, сделав вывод из того о чем даже не слышали.
я обязательно изменю своё мнение, когда увижу эфективную реализацию БЛ на функциональных, а так же процедурных языках. а пока....
Лойда часто минусуют, но я с ним полностью согласен. Приятно видеть человека, который чётко и правильно что-то для себя осознал (что такое ООП) и может это продемонстрировать.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Enomay, Вы писали:
G>>Как ты такое будешь хранить? Это надо вычислять.
E>совершенно необязательно. это достаточно вычислять 1 раз при оформлении пользовательского заказа.
Это надо вычислять постоянно, чтобы пользователь видел какую сумму он заплатит.
E>>>и о ужас! в основе её лежит доменная модель!!! G>>не-а, в её основе лежать очереди и воркеры, а доступ к данным может быть абсолютно любым.
E>вот видишь. то потому что ты видишь только то, что хочешь. E>но открою секрет, в середине лежит домен, который обрабатывает команды. E>посмотрю любую схему CQRS. там по центру есть такое, Domain Model называется.
Я за схемами еще и суть вижу. Думаешь если заменить domain model на обычные сервисы, которые ставят сообщения в очереди что-нить изменится? Ничего не изменится, только код проще станет. Я такое уже писал лет 5 назад и искренне смеялся когда увидел пафос вокруг CQRS.
Хотя domain model без CQRS плохо живется, как раз по причине того что в честном domain model просто так произвольный запрос не сделаешь.
G>>Слушал, такой бред рассказывает что смешно. E>а ты наверное умнее?
Нет, я такой бред не рассказываю на конференциях.
E>>>опять какие-то глупости пошли. E>>>в основе сервисов лежит DDD. это даже у Эванса есть. G>>А у меня нет, у меня сервиcы без DDD. E>не могу сказать что рад за тебя, но зачем мне эта информация?
Затем чтобы ты понимал что для сервиов ddd не нужен. DDD вообще не ненужен.
E>>>а иначе что делает сервис? тупо возвращает данные? G>>Когда надо возвращать — возвращает. Когда надо изменять — изменяет E>а логика изменения данных где лежит?
не поверишь — тоже в сервисах.
E>>>без проблем. используй анемик. разве тебя кто-то заставляет писать по другому? E>>>тебя даже никто не пытается переубедить. G>>Я хочу понять зачем использовать rich.
E>так попробуй понять это. напряги мозг, подумай. иначе никак не получится. никто тебе тут в примерах и сравнениях не покажет чем одно лучше другого, особенно когда оппонент не способен адекватно воспринимать информацию.
То есть явных преимуществ нет, и каждый должен их сам выдумывать чтоли?
E>я кажется и не требовал признания тобой моих слов) E>то тебе лень гуглить, то ты пишешь что хочешь понять зачем использовать рич. так хочешь все же, или лень?
Не выкручивайся, дай ссылку просто.
E>>>реализация логики в сервисе, это конечно можно. для процедурного программирования. но ООП как бы говорит о другом. и я придерживаюсь последнего подхода, в отличии от тебя. G>>А зачем ты его придерживаешься, что оно тебе дает?
E>ответ на этот вопрос уже звучал в этом треде. E>так же можешь почитать что-то на тему ООП, наверняка там будут описаны профиты.
То есть ты не знаешь.
E>>>эффективности при решении задач оно не убавляет. для больших проектов выгода очевидна. G>>Убавляет, тупо потому что больше кода писать надо.
E>выигрыш не в кол-ве строк, а в гибкости архитектуры.
И в гибкости архитектуры тоже. Например для масштабирования не надо прикручивать CQRS. SOA и так прекрасно масштабируется.
E>>>и опять ты кидаешься в крайности. для тебя если DDD, то материализовать всё. но это не так. G>>Ок, приведи пример где это не так. У тебя же логика в классах и без ссылки на класс ты её вызывать не можешь.
E>в CQRS модели шлем команду, обработчик которой вытаскивает при необходимости из базы дополнительные данные и передаёт все это модели, та уже выполняет логику. но варианты могут быть и другие.
Да сервис "шлет команду" (по сути ставит в очередь), другой сервис по этой "команде" запускается, выполняет обработку и сохраняет данные. Может еще другие "команды" слать. Это давно известная архитектура.
E>>>ты и такую задачу реализовать не можешь? G>>См SQL выше. Его же можно с помощью LINQ нагенерить (что я собственно и сделал в подобной задаче). E>это же можно использовать и в DDD. ничто не мешает.
В каком месте писать запрос? Внутри доменного объекта? Это неправильно с точки зрения DDD. В отдельном сервисе? Тогда зачем доменные объекты?
E>очень тяжело что-то объяснять человеку, который совершенно не понимает ООП, более того, считает при этом его ущербным. это как минимум бесполезное занятие.
Ты сам себе противоречишь. Чтобы считать что-то ущербным надо это понимать.
E>по этой причине я не стану ничего писать. но ты можешь прочесть пару книг, возможно это тебе поможет.
Я много книг прочитал, корреляция прочитанного с опытом показывает ущербность. Ты не видишь ущербности потому что у тебя достаточно опыта нету.
G>>Нет, я требую примеры кода от таких троллей, которые пишут лозунги и после каждого второго слова ссылаются на эванса, фаулера или еще кого. G>>Code talks.
E>может быть ты начнешь приводить свой код уже? а так же то, как ты видишь, оно должно выглядеть с точки зрения DDD, в твоей интерпретации. тогда предметно поговорим.
Так вот я и не знаю как оно должно выглядеть в DDD чтобы быть DDD , но достаточно эффективным. Все подходы эванса и фаулера веду к неэффективному коду, а мне тут постоянно доказывают что код будет эффективен.
E>>>опять глупости понеслись. Domain Model как раз очень четко вписывается в SRP, в отличии от твоих сервисов. G>>Ага, особенно одновременное совмещение задач по переносу данных и БЛ. Ведь ты можешь разделить эти обязанности без потери других характеристик, это само существование anemic показывает.
E>доменная модель не переносит никакие данные. она лишь хранит собственное состояние.
Да, а как состояние моедли отображается на экране? Создаются DTO для этого, которые в точности копируют структуру модели? Или как еще?
E>тебе уже намекали не один раз, твоя проблема — ты идешь от данных. в ООП нужно идти от модели. по этой причине ты не можешь понять.
Это не проблема, это преимущество, позволяющее писать меньше кода и сделать его более эффективным.
E>>>на самом деле наличие классов, наследование, полиморфизм и инкапсуляция, абсолютно не делают подход объектно ориентированным. у тебя класс это лишь объединение подобных по смыслу функций. G>>Да, это называется "инкапсуляция поведения".
E>поведение не бывает без состояния
Кто тебе такую глупость сказал?
E>а у тебя его нет, так как ты работаешь в основном с внешними данными
Именно, и ты тоже работаешь с внешними данными
E>в конце концов, прочти хотя бы основные паттерны проектирования, и ты поймешь, что они не ложатся на анемичную модель.
Не говори глупости наиболее востребованные паттерны: стратегия, команда, фабрика, декоратор, медиатор, composite, proxy и многие другие. Они как раз про поведение, а не про состояние. Среди большинства паттернов про состояние только builder и то целью его является переход от mutable к immutable, что вообще говоря является особенностью поведения.
E>>>а вот поведения объектов у тебя нет. G>>Есть, у меня данных в этих объектах нет. E>я писал выше. у тебя не объект, а сборище методов. в паскале это называлось — модуль.
да, это и есть модуль. Но в ОО-яызках есть интерфейсы, позволяющие делать loose coupling между модулями. Это очень хорошо.
E>>>но зато ты и сам подтвердил свою причину непонимания DDD — ты не знаешь что такое ООП и не умеешь его применять на практике. отсюда и процедурный подход, которым ты так гордишься. G>>Ты расстроешься, но я прекрасно знаю ООП во всех его инкарнациях, именно поэтому оно не вызывает у меня такой бури юношеских эмоций как у тебя. E>у меня оно вызывает понимание проблемы и её решение.
Эта тема началась с того что человек не смог с помощью ООП придумать решение конкретной проблемы.
Может ты расскажешь как с помощью ООП спроектировать анализатор трафика?
E>>>>>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно. G>>>>Не очевидно, докажи. E>>>если тебе это не очевидно, могу только по соболезновать. G>>Это тебе соболезновать надо. Ты говоришь глупость, сам в нее свято веришь и при этом не понимаешь тех кто не верит в нее. G>>Такое бывает у сектантов и у сумасшедших. Хотя апологеты DDD проявляют черты и тех и других
E>вот видишь, от собственного бессилия ты начал переходить на личности и хамить.
Если что это ты первый начал, но я решил тебя носом в это не тыкать.
Тем не менее это не отменяет факт твоего поведения близкого к сектантскому.
E>что в очередной раз подтверждает моё мнение о тебе, как довольно слабом программисте. впрочем, интернет магазины тоже кто-то должен писать.
Ты много интернет магазинов сделал? Наверное стоит пробовать устриц чтобы рассуждать об их вкусе.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Неужели математической доказательство может отметить сложности технической реализации ? G>>Разве это отменяет возможность?
I>Я то говорил про сложность
Не выкручивайся.
I>То есть ты уверен, что всегда есть возможность написать один запрос который получает все данные ?
Где тут упоминание про сложность?
I>>>Каюсь, не знал. Я то думал на каждую операцию надо время, хотя бы и маленькое, а оказывается математика может _любую_ операцию сделать равной нулю по затратам времени. Не подскажешь, почему эта математика не может сделать так, что бы твой комп хотя бы загружался или просыпался за ровно 0 секунд ? G>>А ты считаешь что другие способы обработки большого объема данных будут быстрее? Написать sum в запросе гораздо проще, чем циклы и if_ы которые суммируют числа.
I>Ты еще 2+2 предложи в качестве примера
Так в том и прикол что запросы к БД обычно достаточно простые, а если попытаться сделать тоже самое в коде будет гораздо больше писаниниы.
I>Я считаю, что издержки select N+1 запросто могут быть наименьшими сравнивая с другими решениемя.
Предложи другое решение. Задача: для получения величины скидки необходимо получить сумму всех покупок без скидок за последний месяц.
I>>>>>Я немного не точно выразился, selеct n+1 это проблема реализации, но это пробема вторичная, реальная причина в самой предметной области, т.е. в той задаче которую хочет решить заказчик — слишком большой объём выборки для вычисления определенной функции. Слишкой большой это относительно возможностей современных технологий. G>>>>Ни разу он не большой. I>>>Это в твоих задачах объёмы небольшие. G>>Какая разница? Это отменяет тот факт что select n+1 — проблема реализации? I>Читай выделеное.
Слишком большой объем выборки — твоя выдумка.
I>>>Какие такие ? Ты уверен, что за 0.5с для реакции на мышиный клик, твой SQL Server подтянет любое необходимое количество инфы, которую нужно будет еще процессить дополнительно ? Чудеса, ты нашел сервер с бесконечно высокой скоростью, ну ка, поделись этой пулькой I>>>Я вот точно знаю, что для многих задач даже секунд будет недостаточно даже для того, что бы только подтянуть инфу, а у тебя какое то чудо выходит G>>Конечно получить список заказов для кастомера за последний месяц и всех его позиций с суммированием по цене SQL Server сделает достаточно быстро, чтобы уложиться в 0.5 сек. Главное сделать индексы правильные.
I>Я и говорю — это в твоих задачах надо мелочовку таскать вроде заказов за месяц.
Что ты этим хочешь сказать? Задача есть, она хорошо решается запросом и плохо решается кодом. Причем объемы обрабатываемых данных ограничен сверху, так как один клиент не будет больше какого количества в месяц покупать.
I>>>См. пример про смешение цветов. G>>Скопируй сюда чтоли, у меня книги под рукой нет. I>Книга у меня бумажная и дома, где нет компа
ну тогда вкратце суть. Я тоже не дома и книга от меня далеко.
E>>совершенно необязательно. это достаточно вычислять 1 раз при оформлении пользовательского заказа. G>Это надо вычислять постоянно, чтобы пользователь видел какую сумму он заплатит.
вычислять нужно скидку, а сумму заказов за текущий месяц достаточно вычислять только на момент оформления очередного заказа.
G>Я за схемами еще и суть вижу. Думаешь если заменить domain model на обычные сервисы, которые ставят сообщения в очереди что-нить изменится? Ничего не G>изменится, только код проще станет. Я такое уже писал лет 5 назад и искренне смеялся когда увидел пафос вокруг CQRS.
да да, ты гениален. только о тебе никто не знает. и мнение твое никого не волнует.
G>Хотя domain model без CQRS плохо живется, как раз по причине того что в честном domain model просто так произвольный запрос не сделаешь.
в домене не нужно делать произвольные запросы. они делаются до нее.
E>>не могу сказать что рад за тебя, но зачем мне эта информация? G>Затем чтобы ты понимал что для сервиов ddd не нужен. DDD вообще не ненужен.
тебе — не нужен. людям понимающим что это, и умеющим это применять — нужен.
все же просто.
E>>а логика изменения данных где лежит? G>не поверишь — тоже в сервисах.
тоесть, в процедурах. впрочем, об этом я уже говорил.
E>>так попробуй понять это. напряги мозг, подумай. иначе никак не получится. никто тебе тут в примерах и сравнениях не покажет чем одно лучше другого, особенно когда оппонент не способен адекватно воспринимать информацию. G>То есть явных преимуществ нет, и каждый должен их сам выдумывать чтоли?
что бы понять приимущства — нужно понять её. а непонимание и неумении её применять — не делает её говном. да. но ты все никак не хочешь этого понять.
E>>ответ на этот вопрос уже звучал в этом треде. E>>так же можешь почитать что-то на тему ООП, наверняка там будут описаны профиты. G>То есть ты не знаешь.
твое право считать как хочешь
E>>в CQRS модели шлем команду, обработчик которой вытаскивает при необходимости из базы дополнительные данные и передаёт все это модели, та уже выполняет логику. но варианты могут быть и другие. G>Да сервис "шлет команду" (по сути ставит в очередь), другой сервис по этой "команде" запускается, выполняет обработку и сохраняет данные. Может еще другие "команды" слать. Это давно известная архитектура.
конечно известная. просто в основе лежат разные принципы и разные реализации.
E>>это же можно использовать и в DDD. ничто не мешает. G>В каком месте писать запрос? Внутри доменного объекта? Это неправильно с точки зрения DDD. В отдельном сервисе? Тогда зачем доменные объекты?
для инкапсуляции логики, конечно же.
E>>очень тяжело что-то объяснять человеку, который совершенно не понимает ООП, более того, считает при этом его ущербным. это как минимум бесполезное занятие. G>Ты сам себе противоречишь. Чтобы считать что-то ущербным надо это понимать.
или наоборот, не понимать.
E>>по этой причине я не стану ничего писать. но ты можешь прочесть пару книг, возможно это тебе поможет. G>Я много книг прочитал, корреляция прочитанного с опытом показывает ущербность. Ты не видишь ущербности потому что у тебя достаточно опыта нету.
о да. ты конечно же можешь судить о моем опыте
а может быть ты считаешь это ущербной технологией, потому что ума не хватает понять ее?)
ведь на бейсике писать может каждый. а применять ООП увы.
E>>может быть ты начнешь приводить свой код уже? а так же то, как ты видишь, оно должно выглядеть с точки зрения DDD, в твоей интерпретации. тогда предметно поговорим. G>Так вот я и не знаю как оно должно выглядеть в DDD чтобы быть DDD , но достаточно эффективным. Все подходы эванса и фаулера веду к неэффективному коду, а мне тут постоянно доказывают что код будет эффективен.
это потому что ты не способен написать эффективный код.
начал бы приводить то что получается, возможно тебе бы подсказали, в каком месте ты ошибаешься.
E>>доменная модель не переносит никакие данные. она лишь хранит собственное состояние. G>Да, а как состояние моедли отображается на экране? Создаются DTO для этого, которые в точности копируют структуру модели? Или как еще?
зависит от потребностей. в некоторых случаях модель себя никак не отображает на экране. для этого есть собственно query, в СQRS.
E>>тебе уже намекали не один раз, твоя проблема — ты идешь от данных. в ООП нужно идти от модели. по этой причине ты не можешь понять. G>Это не проблема, это преимущество, позволяющее писать меньше кода и сделать его более эффективным.
не всегда в основе логики лежат данные, в том виде, в котором ты их воспринимаешь.
твое преимущество выплывает лишь в написании интернет магазинов.
E>>поведение не бывает без состояния G>Кто тебе такую глупость сказал?
поведение основано на каких-то данных, на основе которых принимается решение. а иначе это банальное действие.
E>>а у тебя его нет, так как ты работаешь в основном с внешними данными G>Именно, и ты тоже работаешь с внешними данными
нет. это ты смотришь на все данные — как на внешние, потому что во главе твоей архитектуры база данных.
E>>в конце концов, прочти хотя бы основные паттерны проектирования, и ты поймешь, что они не ложатся на анемичную модель. G>Не говори глупости наиболее востребованные паттерны: стратегия, команда, фабрика, декоратор, медиатор, composite, proxy и многие другие. Они как раз про поведение, а не про состояние. Среди большинства паттернов про состояние только builder и то целью его является переход от mutable к immutable, что вообще говоря является особенностью поведения.
они работают с объектами, которые имеют состояние. ты опять смотришь с другой стороны.
E>>я писал выше. у тебя не объект, а сборище методов. в паскале это называлось — модуль. G>да, это и есть модуль. Но в ОО-яызках есть интерфейсы, позволяющие делать loose coupling между модулями. Это очень хорошо.
ООП это не прибавляет)
G>Эта тема началась с того что человек не смог с помощью ООП придумать решение конкретной проблемы. G>Может ты расскажешь как с помощью ООП спроектировать анализатор трафика?
для анализатора трафика совершенно не обязательно применять ООП.
это же как микроскопом гвозди забивать.
E>>вот видишь, от собственного бессилия ты начал переходить на личности и хамить. G>Если что это ты первый начал, но я решил тебя носом в это не тыкать. G>Тем не менее это не отменяет факт твоего поведения близкого к сектантскому.
нет. я просто троллю, а ты впадаешь в крайности считая свой подход единственно верным.
E>>что в очередной раз подтверждает моё мнение о тебе, как довольно слабом программисте. впрочем, интернет магазины тоже кто-то должен писать. G>Ты много интернет магазинов сделал? Наверное стоит пробовать устриц чтобы рассуждать об их вкусе.
и не только магазинов. но к делу это не относится.
Здравствуйте, Enomay, Вы писали:
E>>>вызов update как следствие работы доменной модели, но не на прямую, конечно же. S>>Это значит что модель предметной области не решает, где и какой update делать? Или решает таки?
E>вызов update — это следствие работы доменной модели.
Весьма туманно
E>>>возьмем 10 процедур. 3 структуры. они друг с другом взаимодействуют. все это написано на Object Pascal. Будет ли это ООП? S>>Ответ на этот вопрос зависит не от количества процедур, структур, и не от языка, на котором выполнено взаимодействие. Построенное определенным образом взаимодействие вполне можно будет квалифицировать как ООП.
E>мне кажется количество как раз не является решающим фактором. 10 классов не делает подход более ООП, чем 2. E>а вот взаимодействие, бесспорно. может.
Я об этом и написал, разве нет?
E>но мы говорим о конкретной реализации — энемичной модели. E>а она, реализации, как раз на ООП не особо то и похожа, на мой взгляд.
На мой взгляд программа состоит не только из модели предметной области.
S>>В вашем DDD (в вашей трактовке его) кроме объектов домена разве нет других объектов? На каком основании вы полагаете что раз у объектов домена не наблюдается S>поведение, то вся программа будет состоять из процедур и структур? Или вы так не считаете? К чему тогда пример с Object Pascal-ем?
E>разве я говорил что других объектов нет? конечно же есть. но мы говорим о ядре, как я понимаю.
Слово ядро впервые упомянуто в этом топике. Напротив, вы тут приводили аналогии с Object Pascal-ем где не было разделения 10 процедур на ядро и остальное. E>но вполне вероятно, если человек использует процедурный подход для реализации бизнес логики, то он придерживается этого стиля и в остальных частях.
S>>Нечего тут брать. Некоторая сущность... обладающая определенным состоянием и поведенеим... Как правило.... S>>А вот по мнению Кея "Все является объектом".
E>у Кея, имхо, правильная трактовка, но дополнения, мне кажется, были введены для разграничения ООП (DDD) от не ООП (анемик)
Такого разграничения нет. Есть rich vs anemic. DDD типично строится на rich модели, но не ограничена ею со слов Э. и Ф.
S>>Если вы классифицируете программы только по исполнению модели предметной области — то это ваше право... E>не нужно мне приписывать чужого. я не классифицировал программы.
прошу прощения, подходы
а вот anemic, в общем-то, не является ООП подходом.
E>мы говорим о вариантах реализаций. при том беспредметно. весь этот тред, в общем-то, ни о чем.
Верно. И в том что он ни о чем — частично и ваша заслуга. Вы делаете сильные утвреждения и подтверждаете их фразами "я не слышал" и "вероятно".
S>>, сделав вывод из того о чем даже не слышали.
E>я обязательно изменю своё мнение, когда увижу эфективную реализацию БЛ на функциональных, а так же процедурных языках. а пока....
Раньше об эффективности не было ни слова. По вашему их просто не существовало...
Ну что же, а я не видел эффективных реализаций БЛ на рич DDD, таких, что нельзя было бы сделать эффективнее, перейдя к анемику, процедурщине, функциональщине. Но я из этого не делаю никаких выводов
Здравствуйте, gandjustas, Вы писали:
I>>>>Неужели математической доказательство может отметить сложности технической реализации ? G>>>Разве это отменяет возможность? I>>Я то говорил про сложность G>Не выкручивайся.
Я и не выкручиваюсь, если прочтешь выделеное внимательно, сам всё поймёшь.
G>
I>>То есть ты уверен, что всегда есть возможность написать один запрос который получает все данные ?
G>Где тут упоминание про сложность?
Это намёк такой, что есть задачи посложнее тех с которыми ты имел дело.
I>>Ты еще 2+2 предложи в качестве примера G>Так в том и прикол что запросы к БД обычно достаточно простые, а если попытаться сделать тоже самое в коде будет гораздо больше писаниниы.
Думаешь если запросы простые так и задача будет простой ?
I>>Я считаю, что издержки select N+1 запросто могут быть наименьшими сравнивая с другими решениемя. G>Предложи другое решение. Задача: для получения величины скидки необходимо получить сумму всех покупок без скидок за последний месяц.
Это ж ты говоришь, что select N+1 означает что ДДД может рожать только тормозные решения. Вот и предлагай решение
Я говорю о том, что проблема select N+1 есть следствие сложности задачи и вполне может быть приемлимой по издержкам относительно других способов.
I>>>>Это в твоих задачах объёмы небольшие. G>>>Какая разница? Это отменяет тот факт что select n+1 — проблема реализации? I>>Читай выделеное. G>Слишком большой объем выборки — твоя выдумка.
Не выдумка а факты. Я понимаю, что ты не веришь ни во что, кроме своих задач Но это ж не оправдание.
I>>Я и говорю — это в твоих задачах надо мелочовку таскать вроде заказов за месяц.
G>Что ты этим хочешь сказать? Задача есть, она хорошо решается запросом и плохо решается кодом. Причем объемы обрабатываемых данных ограничен сверху, так как один клиент не будет больше какого количества в месяц покупать.
Я ж сказал — это мелочовка.
I>>Книга у меня бумажная и дома, где нет компа G>ну тогда вкратце суть. Я тоже не дома и книга от меня далеко.
Не, ты ведь рассказывал что прочёл книгу ? И вдруг оказыается что даже вспомнить не можешь
Здравствуйте, Enomay, Вы писали:
E>>>насчет размазывания логики по нескольки объектам, ну так это ж банальный принцип "ответственности" из SOLID, да и ООП в целом. так что это правильная реализация. G>>В SOLID куча других принципов, да и за пределами SOLID тоже, и DDD, как его описывает эванс, многое нарушает.
E>нет, DDD это классическое ООП, и ничего не нарушает.
Эванс сам говорит, что для ДДД не важна ни архитектура, ни парадигма
E>>вызов update — это следствие работы доменной модели. S>Весьма туманно
проблема DDD ненавистников в том, что Эванс не разжевал и не разложил по полочкам, в том числе и на примерах кода, жизненный цикл программы. Кто, кого и зачем вызывает.
Он лишь даёт общие рекомендации. А вот кто и как это реализует, другое дело.
И люди часто прочитав Эванса, который описывает DDD методологию как решающую определенный набор проблем, замечу, не серебряную пулю, воодушевившись этим, пытаются применять написанное, не понимая что к чему. Толи опыт, толи еще что)
отсюда, после и берутся такие как мой оппонент, требующие! примеры реализаций, потому что сами не в состоянии этого сделать. они не хотят думать и эксперементировать, учиться новом, они хотят что бы им прямо показали почему оно лучше. но ведь так не бывает.
E>>но мы говорим о конкретной реализации — энемичной модели. E>>а она, реализации, как раз на ООП не особо то и похожа, на мой взгляд. S>На мой взгляд программа состоит не только из модели предметной области.
конечно! более того, DDD не является панацеей и для решения многих задач вообще не приемлема. как и ООП в целом. но те кто узко мыслит, думает что раз Эванс сказал — DDD — это круто, значит это должно быть круто и его нужно пихать куда попало. но не получается.
E>>у Кея, имхо, правильная трактовка, но дополнения, мне кажется, были введены для разграничения ООП (DDD) от не ООП (анемик) S>Такого разграничения нет. Есть rich vs anemic. DDD типично строится на rich модели, но не ограничена ею со слов Э. и Ф.
возможно и не ограничена. я реализаций не встречал. возможно они будут эффективны. не знаю.
E>>мы говорим о вариантах реализаций. при том беспредметно. весь этот тред, в общем-то, ни о чем. S>Верно. И в том что он ни о чем — частично и ваша заслуга. Вы делаете сильные утвреждения и подтверждаете их фразами "я не слышал" и "вероятно".
я лишь троллю своего оппонента и это довольно забавно. но я ни в коем случаи не пытаюсь тут что-то доказать, и даже не делал никаких безапелляционных громогласных заявлений. и не пытаюсь сравнивать две архитектуры.
не скрою, данная тема мне была бы интересна, будь она основана на чем-то. а так, как я уже писал, это легкий троллинг)
при этом, оппонент пытается мне доказать что-то, что мне совершенно не нужно и не интересно.
но это все лирика.
Здравствуйте, Enomay, Вы писали:
E>>>вызов update — это следствие работы доменной модели. S>>Весьма туманно
E>проблема DDD ненавистников в том
лирика. Но разве поклонникам DDD яснее, что означает "вызов update — это следствие работы доменной модели" после утвреждения что именно объект предметной области решает когда и как вызвать update?
E>>>но мы говорим о конкретной реализации — энемичной модели. E>>>а она, реализации, как раз на ООП не особо то и похожа, на мой взгляд. S>>На мой взгляд программа состоит не только из модели предметной области.
E>конечно! более того, DDD не является панацеей и для решения многих задач вообще не приемлема. как и ООП в целом. но те кто узко мыслит, думает что раз Эванс сказал — DDD — это круто, значит это должно быть круто и его нужно пихать куда попало. но не получается.
Я не пытался соскочить из области традиционного применения DDD куда-нибудь в компиляторостроение или компьютерное зрение. Я лишь отметил что считаю что в программе кроме модели предметной области есть и другие вещи. В ответ получил лирику про то что DDD не панацея.
S>>Такого разграничения нет. Есть rich vs anemic. DDD типично строится на rich модели, но не ограничена ею со слов Э. и Ф.
E>возможно и не ограничена. я реализаций не встречал. возможно они будут эффективны. не знаю.
Отлично. Я тоже не встречал. Более того, совершенно не представляю как по исходникам проекта написанного в DDD стиле но не в рич или вообще не в ООП, понять что он написан в духе DDD. Да и с ричем тоже. Проект может обладать свойствами, характерными для DDD в то время как его авторы даже не слышали о нем. Так же может не обладать свойствами DDD, даже в том случае если авторы думали что писали его в духе DDD.
E>>>мы говорим о вариантах реализаций. при том беспредметно. весь этот тред, в общем-то, ни о чем. S>>Верно. И в том что он ни о чем — частично и ваша заслуга. Вы делаете сильные утвреждения и подтверждаете их фразами "я не слышал" и "вероятно".
E>я лишь троллю своего оппонента и это довольно забавно.
Тогда я завязываю попытки докопаться до смысла ваших утвреждений, либо добиться смягчения их формы. Развлекайтесь
Здравствуйте, Sinclair, Вы писали:
L>>Эта формулировка все-таки существенно отличается от "ООП — оно целиком про поведение". S>Ну так я и не статью в рецензируемый журнал пишу.
Понимаешь в чем цимес, если выпячивать только эту сторону, то выходит, что процедурный подход более ООПшен, чем ОО, ибо в процедурах кроме поведения нет вообще ничего.
В ветке, где обсуждается процедурность vs объектная-ориентированность более логично подчеркивать тот аспект которые отличает эти две парадигмы, а не тот, что их сближает.
В этом отношении определение ООП из википедии вполне корректно, а цитаты Алана Кея — совсем неуместны.
Здравствуйте, Lloyd, Вы писали:
L>>>Эта формулировка все-таки существенно отличается от "ООП — оно целиком про поведение". S>>Ну так я и не статью в рецензируемый журнал пишу.
L>Понимаешь в чем цимес, если выпячивать только эту сторону, то выходит, что процедурный подход более ООПшен, чем ОО, ибо в процедурах кроме поведения нет вообще ничего.
А покажи-ка процедурную реализацию стека.
L>В ветке, где обсуждается процедурность vs объектная-ориентированность более логично подчеркивать тот аспект которые отличает эти две парадигмы, а не тот, что их сближает.
Вот вот, покажи пример со стеком и тебе сразу станет всё понятно.
Здравствуйте, Ikemefula, Вы писали:
L>>Понимаешь в чем цимес, если выпячивать только эту сторону, то выходит, что процедурный подход более ООПшен, чем ОО, ибо в процедурах кроме поведения нет вообще ничего.
I>А покажи-ка процедурную реализацию стека.
Сам осилишь: cтруктурка с указателем на вершину стека + пачка методов.
Здравствуйте, samius, Вы писали:
E>>возьмем 10 процедур. 3 структуры. они друг с другом взаимодействуют. все это написано на Object Pascal. Будет ли это ООП? S>Ответ на этот вопрос зависит не от количества процедур, структур, и не от языка, на котором выполнено взаимодействие. Построенное определенным образом взаимодействие вполне можно будет квалифицировать как ООП.
Это будет не ООП, а эмуляция ООП или ООП-стиль. Во всех букварях подробно объясняется, почему такой подход будет не ООП
Здравствуйте, Lloyd, Вы писали: L>Понимаешь в чем цимес, если выпячивать только эту сторону, то выходит, что процедурный подход более ООПшен, чем ОО, ибо в процедурах кроме поведения нет вообще ничего.
Нет. В процедурном подходе нет идентичности, что ещё более приоритетно, чем поведение.
L>В ветке, где обсуждается процедурность vs объектная-ориентированность более логично подчеркивать тот аспект которые отличает эти две парадигмы, а не тот, что их сближает. L>В этом отношении определение ООП из википедии вполне корректно, а цитаты Алана Кея — совсем неуместны.
В ветке происходит странная борьба между неправильным пониманием ООП и неправильным пониманием процедурного подхода.
Чтобы понять, почему анемик не является менее ООП, достаточно отойти чуть назад и задуматься.
Постулат номер 1: ООП — оно не про моделирование задачи. Оно про моделирование решения.
Пример, который я уже приводил: чтобы управлять лампочкой, не нужно моделировать лампочку. Нужно моделировать выключатель.
Точно так же и в документообороте. Не нужно моделировать сам документ — нужно моделировать бюрократа, который выполняет workflow.
Точно так же в бухгалтерии — не надо моделировать "проводку". Надо моделировать "сведение баланса".
Постулат номер 2: ООП не про данные, ООП про поведение.
Поэтому не надо радоваться, увидев похожие реквизиты у товарной накладной и у приходного ордера, и бежать наследовать их друг от друга. В соответствии с постулатом номер 1 мы уже выяснили, что у накладных собственного поведения, в общем-то, нет. Их структура меняется крайне редко, зато вот правила обращения с ними — чуть ли не каждый день.
Вот тут и оказывается, что анемика предлагает размещать логику в "сервисах" — решателях задачи. Если там есть сервисы с похожим поведением — то весь арсенал ООП вам в помощь. Надо — наследуйтесь, не надо — агрегируйте. Если есть действие, в котором участвует три разных объекта предметной области — значит, будет такое действие.
А рич-модель бесплодно пытается приделать офицерской вдове метод "высечь". Или вместо того, чтобы породить экскаватор, пишет земля.копайся().
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Enomay, Вы писали:
E>ошибаешься, доменные объекты есть. именно они и решают где и какой update сделать.
E>а вот anemic, в общем-то, не является ООП подходом. E>разные реализации. ты используешь процедурный подход, мы ООП. E>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно.
Вы неправильно понимаете ООП. Анемик ничуть не менее ООП, чем рич. Вы просто ищете объекты не там, где надо.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
E>>а вот anemic, в общем-то, не является ООП подходом. E>>разные реализации. ты используешь процедурный подход, мы ООП. E>>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно. S>Вы неправильно понимаете ООП. Анемик ничуть не менее ООП, чем рич. Вы просто ищете объекты не там, где надо.
возможно. но мне почему-то казалось что подсчетом стоимости заказов должен заниматься объект Order, а не OrderService.
