Здравствуйте, AndrewVK, Вы писали:

L>>Давайте зайдем с другой стороны — есть хоть что-нибудь, что не является ОО?

AVK>Очень простой вопрос. Есть.

Вольно.

Здравствуйте, gandjustas, Вы писали:
G>Снаружи нет возможности идентифицировать конкретный сервис, вернее экземпляр сервиса. Это и есть отсутствие идентичности.
G>Снаружи мы можем говорить только об эквивалентности. И с точки зрения SOA все сервисы с одинаковым контрактом эквивалентны.
Ок, может быть. Я не столь силён в SOA. Неужели там все сервисы предполагаются stateless?
Я как-то плохо себе представляю вот эту "эквивалентность". Вот есть у меня, допустим, контракт на OrderTracking.
Он типа весь стандартный. И что, мне должно быть пофигу, вызывать его для Fedex, UPS, или DHL?

Здравствуйте, Lloyd, Вы писали:

L>У меня есть сомнение, что можно говорить об идентичности в случае когда речь идет об одном экземпляре.
Судя по википедии, предполагается некая стандартизация сервисов. Т.е. один и тот же контракт исполняют многие сервисы.
L>А какое это имеет значение?
Да, верно.

L>Нет, не помню, как впрочем и вы.

Здравствуйте, Enomay, Вы писали:

E>

E>GetPrice(int count)
E>{
E>   return count > кол-во_без_скидки ? кол-во_без_скидки * price : count * price;
E>}
E>

E>как-то так.
E>это, конечно, тупая реализация, с опущенными вариантами получения разных типов скидок.
Прекрасно, что вы это понимаете.
Плохо, что вы на полном серьёзе предлагаете такую реализацию:
1. У вас появились в задаче скидки. Вы моментально меняете контракт класса Product.
2. Предлагаемые вами изменения никак не помогут вам описать следующую скидку, которую попросят. Вам снова придётся менять контракт — а, значит, переделывать и перетестировать все зависимые классы.
Вам самому не очевидно, что в приличной архитектуре такие задачи должны решаться в худшем случае дописыванием нового класса, а в нормальном случае — конфигурацией определённых объектов?
До ошибки в реализации докапываться не буду — будем считать, что вы не поняли, что означает скидка "купившему два третий бесплатно".

E>а скидки по конкретному продукту могут описываться хоть в XML.

Описываться-то они, конечно, могут. Вот только интересно было бы посмотреть на код, который пользуется этим описанием.

E>само собой добавление товаров свыше 2х, которые бессплатные, не является обязанностью класса Order.
E>ведь это как в жизни. купил 2, но от 3го бессплатного отказался. не отказался? ок. расчет стоимости корзины все равно останется верным, в данном случае.
Конечно, про это никто и не говорит. Речь идёт исключительно о расчёте цены ордера. Заставить покупать третий экземпляр мы не можем.

E>вся проблема в том, что мы смотрим на вещи по разному. в моем случае Order это грубо говоря корзина с продуктами, если быть точнее — чек.
E>а по этому мой класс Order работает как чек. и лишние товары со скидками, или бесплатные, он сам не добавляет. он считает то, что есть. а вот кто это добавит, не его проблема.
Ваш класс Order пока ещё ничего не считает. Пока что вы вшили в систему ровно один вид скидок, и тот работает неправильно.
Давайте всё же добавим в систему ещё одно реалистичное требование. Давайте сделаем так, чтобы на большинство товаров распространялась накопительная скидка, привязанная к покупателю (скажем, 10%), но для некоторых особо популярных товаров этой скидки не было.
Как это отразится в вашей красивой архитектуре?

E>это и есть, на мой взгляд, SRP. каждый занимается тем, что лучше умеет.
У вас товар занимается определением скидок. Он это умеет плохо.

E>кстати говоря, "купи 3 бутылки пива и 4ю бессплатно" можно рассматривать как 1 еденица товара. обычно они именно в таком виде и продаются. так что делать хитрые условия по скидке 4го товара, после предыдущих 3х, обычно нет необходимости.
Неплохое решение. Требует, правда, от оператора определённой работы (типа как правильно пробить 10 бутылок пива?), но жизнеспособно.
К сожалению, для остальных десятков видов скидок оно не помогает.

E>ну а для уникальных случаев, конечно же, есть соответствующие решения.
Да, я привёл соответствующее решение в этом топике. Вам оно чем-то не нравится.

Здравствуйте, Enomay, Вы писали:

E>это отличается лишь местоположением, от моего подхода. и еще тем, что я работаю с теми данными, которые имею, а вы работаете с внешними.
Совершенно верно. Местоположение, в свою очередь, определяет нефункциональные характеристики решения.

E>если у вас другое мнение, вы в праве делать иначе
Вы можете считать, что аппараты тяжелее воздуха не могут летать. Это не означает, что мы должны решать этот вопрос голосованием.

E>но увеличиваем сложность и площадь сервиса. закон сохранения энергии, да. если что-то где-то пропало, то что-то появится в другом месте )
Нет. 2O(N^2) не то же самое, что O(2N^2).

E>у меня логика лежит ближе к данным, на которые она распространяется. у вас наоборот, как я писал, данные отдельно, логика отдельно.
E>я не против такого решения, и там, где оно уместно, применяю. но если можно вырисовать красивую и функциональную рич модель, я это сделаю.
Я бы тоже не отказался. К сожалению, случаев уместного применения рич-модели я за 19 лет работы не встречал.

E>ну и про тестирование совершенно не аргумент. и тут и там метод. тестируются одинаково. как минимум. более того, у меня еще и разделено все на запчасти, каждая из частей может быть протестирована отдельно от общей инфраструктуры. сервисы обычно все же жощще завязаны.
Вы почему-то сравниваете "хорошую" реализацию рич-модели с "плохой". Я точно так же могу обвинить рич в том, что там вся логика расчёта скидок с километровыми if-ами и подтягиванием 99% содержимого базы в память засунута в несчастный Order. Но зачем?

E>масло масленое какое-то. методы которые работают с данными остаются снаружи, а что же тогда считает сумму заказа, если все данные с другой стороны.
Я же показал вам код — что именно вам непонятно?
Поймите, бывают методы, которые требуют доступа к внутренним данным. И бывают все остальные методы. Гуру ООП советуют вытаскивать все остальные методы наружу — это улучшает инкапсуляцию и cohesion, уменьшает coupling.

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

S>>Вопрос повышенной сложности: а что, если мы добавили в ордер сначала плеер, а потом телевизор?

E>да, это правда очень хороший вопрос. и я с ходу не готов дать на него ответ.
E>могу предположить, что при возрастающей сложности системы расчета заказа, всё это будет обрастать неимоверным кол-вом вспомогательных сервисов.
Я вам привёл код сервиса, который корректно обрабатывает все эти случаи. Никакого "неимоверного" количества не потребуется. Всё, что будет нужно — горсть наследников DiscountRule. Возможно, DiscountRule будут распилены на ещё более мелкие запчасти для уменьшения общего количества кода. Всё это живёт в пространстве имён DiscountService.
Это и есть простая и понятная объектно-ориентированная модель. А то, что вы предлагаете — это городить костыли, искусственно запихивая в объекты несвойственную им функциональность.

E>и он очень близко к вашему решению на основе сервисов.
Это будет по-прежнему далеко от моего решения на основе сервисов. В частности, граф зависимостей будет выглядеть радикально по-иному. Даже если вы скопируете моё решение 1-в-1, только разместив код внутри класса Order.

E>некоторые вопросы на столько абстрактны и каверзны, что несколько отдаляются от действительности, а посему, и ответ на них найти не просто, а часто, и бессмысленно. мы рисуем схему к совершенно абстрактному магазину, требования к которому меняются ежесекундно. у вас есть готовое решение, я за вас рад.
У меня нет готового решения. У меня есть подход, который позволяет легко и непринуждённо генерировать решения к произвольным требованиям. А у вас есть только желание "засунуть логику поближе к данным", которое в жизни будет приводить к постоянному редизайну уже готовой системы.

E>ну вот, еще один человек требует код.
E>но кода не будет. приведи я его вам, вы скажете "ага! а вот эта фишка в нем работать не будет", и будете совершенно правы, так как я не учел её, но лишь потому, что вы заранее её не упомянули.
E>именно по этой причине сие бессмысленно.
Ну а вы как хотели? Это жизнь; водопадная модель не работает. Ваша архитектура должна быть устойчива к изменению требований. Мою модель легко расширять, не трогая готовый функционал. Ваша потребует нудных проверок процедур апгрейдов — потому что вам придётся всё время вносить изменения в существуюший код классов.
E>но, как я уже было предлогал, мы можем поставить задачу и представить 2 разных решения, а дальше вести обсуждении на основе их.

E>если вы вернетесь на пару постов назад, увидите, какие-то остатки, возвраты и прочую ерунду.
Это не ерунда. Речь не об Order, а о других классах той же модели. Вам трижды уже написали, что помимо "чеков", в магазине фигурирует ещё много похожих объектов. И внешний метод расчёта суммы ордера можно повторно использовать. А ваш метод — нельзя.

E>а скидки не участвуют в подсчете суммы товаров заказа?
Участвуют. Просто тогда получается, что ордер не только "суммирует".

E>конечно он может общаться с окружающим миром. разве я это запрещал? или говорил что кто-то другой запрещает?
E>но основная логика класса сконцентрирована на внутренних объектах.
E>возьмите объект Window в .NET. он ведь отрисовывает только свои контролы, а не чужие, правда?
Теперь вы приплетаете сюда ещё и концепцию владения. Давайте не будем об этом разговаривать, а то мне придётся ещё 30 постов объяснять, чем отличается обязанность по контролю за временем жизни от visibility и access control?

E>в восприятии окружающего мира? )
А, ну да.

E>там другая задача, это далеко не интернет магазин, это тонны разнородных данных, которые нужно было агреггировать) но к делу это мало относится.
Ну почему же — очень интересно. Неужели вы приделали к этим данным методы, вместо того, чтобы написать иерархию агрегаторов?

E>хотите отбросить — отбрасывайте. тот подход к реализации, что пропагандирует большинство, при работе с анемик моделью, лично я не считаю true OOP. но это ведь мое мнение, и я его никому не собираюсь навязывать.
Ок, это позиция. Она некорректна, но это нестрашно — достаточно поменять термины. Если переименовать то, что вы называете true OOP, в rich model, то станет намного меньше разногласий.
Также не ожидайте того, что сама по себе rich-ness даст вам какие-то реальные преимущества — ну, кроме морального удовлетворения от Исполнения Заповедей. То есть я и так вижу, что конкретно это преимущество для вас на первом месте, но это со временем пройдёт.

E>это больше похоже на то, что вы сами не уверенны, но если удастся убедить меня, то вы одержите победу над собой, и ваши сомнения развеятся. но увы, я останусь при своём
Не, у меня просто нетерпимость к заблуждениям.

Здравствуйте, Lloyd, Вы писали:

L>Это какой-то новый совершенно выбивающий из колеи прием — я отвечаю на ваш пост, а вы в ответ приводите набор банальностей, на который и возразить вроде нечего.
Эти банальности, судя по содержанию постов, для многих участников топика являются откровением.
Связь очень простая — вы мне пишете, что важно для обсуждения процедурности vs объектно-ориентированности.
А я вам отвечаю, что этого обсуждения здесь нет. Я не могу считать полемику с использованием ереси типа "анемик — это процедурный подход" или "ООП — это данные с методами" реальным обсуждением ООП и процедурности.

Как если бы вы пытались выяснить, к зверям или птице относить сазана.

E>>как-то так.
E>>это, конечно, тупая реализация, с опущенными вариантами получения разных типов скидок.
S>Прекрасно, что вы это понимаете.
S>Плохо, что вы на полном серьёзе предлагаете такую реализацию:
S>1. У вас появились в задаче скидки. Вы моментально меняете контракт класса Product.
S>2. Предлагаемые вами изменения никак не помогут вам описать следующую скидку, которую попросят. Вам снова придётся менять контракт — а, значит, переделывать и перетестировать все зависимые классы.
S>Вам самому не очевидно, что в приличной архитектуре такие задачи должны решаться в худшем случае дописыванием нового класса, а в нормальном случае — конфигурацией определённых объектов?
S>До ошибки в реализации докапываться не буду — будем считать, что вы не поняли, что означает скидка "купившему два третий бесплатно".

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

E>>вся проблема в том, что мы смотрим на вещи по разному. в моем случае Order это грубо говоря корзина с продуктами, если быть точнее — чек.
E>>а по этому мой класс Order работает как чек. и лишние товары со скидками, или бесплатные, он сам не добавляет. он считает то, что есть. а вот кто это добавит, не его проблема.
S>Ваш класс Order пока ещё ничего не считает. Пока что вы вшили в систему ровно один вид скидок, и тот работает неправильно.

опять же, про 2 + 1 бесплатно я писал. этот вариант рассматривается в том же виде, в котором продаётся, и как правило, это 3 вместе скрученых бутылки. вместе 1й строкой мы их и считаем. как и продукт, а не как 3. что вполне разумно.
но да, та реализация не правильная.

S>Давайте всё же добавим в систему ещё одно реалистичное требование. Давайте сделаем так, чтобы на большинство товаров распространялась накопительная скидка, привязанная к покупателю (скажем, 10%), но для некоторых особо популярных товаров этой скидки не было.
S>Как это отразится в вашей красивой архитектуре?

товар вернет цену с учетом накопительной скидки?

E>>это и есть, на мой взгляд, SRP. каждый занимается тем, что лучше умеет.
S>У вас товар занимается определением скидок. Он это умеет плохо.

товар занимается определением собственной цены, с учетом вероятной скидки. для этого у него есть всё необходимое.

E>>кстати говоря, "купи 3 бутылки пива и 4ю бессплатно" можно рассматривать как 1 еденица товара. обычно они именно в таком виде и продаются. так что делать хитрые условия по скидке 4го товара, после предыдущих 3х, обычно нет необходимости.
S>Неплохое решение. Требует, правда, от оператора определённой работы (типа как правильно пробить 10 бутылок пива?), но жизнеспособно.
S>К сожалению, для остальных десятков видов скидок оно не помогает.

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

E>>ну а для уникальных случаев, конечно же, есть соответствующие решения.
S>Да, я привёл соответствующее решение в этом топике. Вам оно чем-то не нравится.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:
G>>Снаружи нет возможности идентифицировать конкретный сервис, вернее экземпляр сервиса. Это и есть отсутствие идентичности.
G>>Снаружи мы можем говорить только об эквивалентности. И с точки зрения SOA все сервисы с одинаковым контрактом эквивалентны.
S>Ок, может быть. Я не столь силён в SOA. Неужели там все сервисы предполагаются stateless?
S>Я как-то плохо себе представляю вот эту "эквивалентность". Вот есть у меня, допустим, контракт на OrderTracking.
S>Он типа весь стандартный. И что, мне должно быть пофигу, вызывать его для Fedex, UPS, или DHL?

Судя по тому что UDDI не пошел в массы скорее всего так и предполагалось. Но не получилось.

Здравствуйте, gandjustas, Вы писали:

G>Адрес не есть Identity. За одним адресом может быть много identity, как в одной квартире могут проживать много человек.
Хороший поинт. Это означает, что граница водораздела проходит по наличию состояния адресата, на которое мы полагаемся. "Принесите деньги в полночь в то место, что я указал в предыдущем письме" — упс, здесь полагаемся на то, что за одним адресом не кроется неопределённое количество identities. Мы полагаемся на то, что получатель письма — ровно тот же, что и в прошлый раз.
Если такое есть — то мы построили ООП поверх очередей сообщений. Если такого нету — то нет и ООП.
Скажем, широковещательная рассылка UDP пакета, упомянутая по соседству, не является ООП.

Здравствуйте, Enomay, Вы писали:

S>>Давайте всё же добавим в систему ещё одно реалистичное требование. Давайте сделаем так, чтобы на большинство товаров распространялась накопительная скидка, привязанная к покупателю (скажем, 10%), но для некоторых особо популярных товаров этой скидки не было.
S>>Как это отразится в вашей красивой архитектуре?
E>товар вернет цену с учетом накопительной скидки?
Как хотите — пусть товар возвращает цену с учётом накопительной скидки. Приведите код в студию. Может быть это несложное упражнение поможет вам понять, почему ваша идея не заслуживает права на применение.

E>товар занимается определением собственной цены, с учетом вероятной скидки. для этого у него есть всё необходимое.
Ну откуда же? У товара ничего этого нет. Вот вам для первой же рассмотренной категории скидок потребовалось срочно внести в товар то, чего в нём не было. Вы добавили атрибут "количество_без_скидки", добавили аргумент "количество" в метод GetPrice().
Для следующей скидки вам придётся снова переделать класс товара.
При этом придётся думать, каким образом реализовать процедуру апгрейда — ведь у вас уже 12000 экземпляров того, старого класса "товар". Структура нового со старым не совпадает. Попробуйте найти в учебниках по ООП ответ на вопрос "как сменить класс у существующего объекта с сохранением его идентичности".
Я смотрю, идея иметь несколько разных потомков для класса Product, в зависимости от стратегии

E>это может быть реализовано как связка товаров, так и другим образом.
E>а вы все время почему-то пытаетесь использовать одну и ту же реализацию для разных случаев скидок. и это плохо получается. что не удивительно.
Почему? Получается прекрасно — я вам в четвёртый раз напомню, что скетч архитектуры, закрывающей вопрос для крайне широкого набора случаев, я привёл ещё вчера. Просто я пользуюсь ООП для решения задачи, а вы — нет.

E>какое имеет значение, нравится оно мне или нет? я ведь не пытаюсь тут кому-то доказать или навязать какое-то решение, в отличии от вас.
Я не навязываю решение. Я показываю, что ваш подход заводит вас в тупик на каждом шаге. А мой приводит к корректным решениям.

Здравствуйте, gandjustas, Вы писали:

S>>Я как-то плохо себе представляю вот эту "эквивалентность". Вот есть у меня, допустим, контракт на OrderTracking.
S>>Он типа весь стандартный. И что, мне должно быть пофигу, вызывать его для Fedex, UPS, или DHL?

G>Судя по тому что UDDI не пошел в массы скорее всего так и предполагалось. Но не получилось.
Не, я не про UDDI. Я про то, что если моя посылка отправлена федексом, то ДХЛ можно хоть заспрашиваться о ней.
То есть — имеем state. Клиентский код для общения с сервисами может быть одним и тем же, но вызов мы отправляем конкретному сервису. Что, очевидно, изоморфно ООПу.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>>>Я как-то плохо себе представляю вот эту "эквивалентность". Вот есть у меня, допустим, контракт на OrderTracking.
S>>>Он типа весь стандартный. И что, мне должно быть пофигу, вызывать его для Fedex, UPS, или DHL?

G>>Судя по тому что UDDI не пошел в массы скорее всего так и предполагалось. Но не получилось.
S>Не, я не про UDDI. Я про то, что если моя посылка отправлена федексом, то ДХЛ можно хоть заспрашиваться о ней.
UDDI как раз долежн позволять скрыть разные сервисы. Мы ему интерфейс — он нам эндпоинт. С этой точки зрения должны быть все сервисы эквивалентны. На практике такое не работает.

S>То есть — имеем state. Клиентский код для общения с сервисами может быть одним и тем же, но вызов мы отправляем конкретному сервису. Что, очевидно, изоморфно ООПу.
Если рассматривать ООП с точки зрения Кея, то и erlang с процессами более чем соответствует. Если же рассматривать ооп с точки зрения Буча, то нет.

Вообще свойство identity в программе выражается в том что для пары объектов можно проверить идентичны они или нет. Для сервисов в общем случае это нельзя сделать. За разнымb эндпоинтами может скрываться один сервис, за одyим эндпоинтам может быть много сервисов (например внутри существлять дисптчеризацию по IP), а может вообще не быть сервиса по указанному эндпоинту.

Поэтому endpoint на роль identity не подходит никак.

E>>какое имеет значение, нравится оно мне или нет? я ведь не пытаюсь тут кому-то доказать или навязать какое-то решение, в отличии от вас.
S>Я не навязываю решение. Я показываю, что ваш подход заводит вас в тупик на каждом шаге. А мой приводит к корректным решениям.

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

Здравствуйте, Enomay, Вы писали:

S>>Это очень хорошо. Осталось только отбросить заблуждения вроде того, что анемик != ООП. или что анемик = функциональный подход.

E>хотите отбросить — отбрасывайте. тот подход к реализации, что пропагандирует большинство, при работе с анемик моделью, лично я не считаю true OOP. но это ведь мое мнение, и я его никому не собираюсь навязывать.
Господа Фаулер и Эванс тоже считают что анемик != тру ООП, полагая что в тру ООП методы кладут рядом с данными. При этом Эванс пишет что иногда все-таки надо класть методы отдельно.

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

Но вместо того, что бы отделять тру-ООП от не тру-ООП, предлагаю сфокусировать внимание на том, что на самом деле мы тут обсуждаем лишь один аспект ООП, который даже напрямую нельзя отнести к ООП, т.к. непонятно откуда он взялся вообще. Это способ определения местонахождения метода по данным, которыми он пользуется.
Мало того, что он не дает однозначный ответ в случае, когда методу нужны данные, расположенные в разных местах, так он еще и может сломает то, из чего он якобы вытекает — инкапсуляцию. Тот же пример, где добавление очередного вида скидки ломает Order.GetTotalPrice().
В данном конкретном примере нет противостояния анемика и ООП. Как только мы придем к тому что ценообразование это не только и не столько сложение цен продуктов, сразу станет очевидно, что вычисление стоимости заказа не обязанность набора продуктов, но это функция от набора продуктов. Так же как и то что вычисление центра масс — не обязанность набора векторов, а функция от набора векторов.

E>я стараюсь использовать другой подход, по возможности, там где это уместно, либо третий, если не работают предыдущие два.
Есть отличный подход, который работает всегда, но к сожалению, плохо формализуем. Здравый смысл. В конкретном примере он мне подсказывает что класть GetTotalPrice в Order — плохая идея. Как и в покупателя или скидку. Даже если бы тру-ООП говорило что других вариантов нет, все равно это было бы плохой идеей в перспективе прогнозируемых изменений в правилах ценообразования. А тру ООП как раз такого не утверждает. Это утверждают несколько тру господ вроде Фаулера и Эванса. Причем, Эванс (повторюсь) сам предлагает отступать от такого тру-ООП.

E>но зачем меня в чем-то убеждать, ума не приложу.
Разубеждать.
E>это больше похоже на то, что вы сами не уверенны, но если удастся убедить меня, то вы одержите победу над собой, и ваши сомнения развеятся. но увы, я останусь при своём
Вы останетесь при своем, даже если вас удастся убедить?
Вам сейчас не навязывают анемик. Спич, как я понимаю, лишь о выборе места для расположения метода и о том что анемик != OOP не истинно. Хотя последнее зависит от того, что подразумевать под тру-ООП и на кого ссылаться.

Здравствуйте, gandjustas, Вы писали:

G>Вообще свойство identity в программе выражается в том что для пары объектов можно проверить идентичны они или нет.
Мы должны проверять идентичность поведения, а тут уже пахнет проблемой останова. Т.е. доказать что объекты идентичны по их поведению невозможно. Можно это лишь опровергнуть. Но при этом объект(ы) возможно изменят свои состояния, так что эта операция небезопасная.

S>Вы останетесь при своем, даже если вас удастся убедить?

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

Здравствуйте, Enomay, Вы писали:

S>>Вы останетесь при своем, даже если вас удастся убедить?

E>для того, что бы меня в чем-то разубедить, я должен быть в чем-то убежден)
E>но я не настаивал на каком-то одном конкретном решении, являющимся голубой таблеткой. я неоднократно говорил что нужно руководствоваться здравым смыслом.
E>но меня по прежнему пытаются в чем-то убедить. но зачем?
Что бы не платить взносы в братстве Истинного ООП, нужно привести последователей

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Flem1234, Вы писали:

F>>Как в SOA же нет состояния.
G>Это неверно.

Это потому что на одинаковые сообщения сервис в праве реагировать по разному?

F>>Нет состояния — нет ООП.
G>Это тоже неверно.

Я думал, что если нет состояния, то ООП тоже нет.

Здравствуйте, samius, Вы писали:

I>>Можешь не тратить месяц — Синклер сделал то о чем я тебя просил всего за одно сообщение.
S>Вот и славно, спасибо Синклеру.
S>Так это была просьба? Я принял ее за предварительный диагноз.
I>>Тренируйся.
S>Только меня не покидает ощущение того, что если бы ты о примере услышал от меня, то повел бы себя иначе.

Я то здесь при чем ? Это ж ты просьбу показать код трактуешь как диагноз

Здравствуйте, Lloyd, Вы писали:

L>>>Вызов процедуры, например.

I>>Где же здесь messaging т.е. взаимодействие объектов через посылку-приём сообщений ?

L>Посылка сообщения — это абстракция любого вызова, не только вызова методов объектов. Для примера, можешь поинтересоваться SOA и очередями сообщений.

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