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

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

I>>>Покажи его.
S>>А то что? А то ты останешься при своем мнении? Да чихать.

I>Ты что, пишешь в форум что бы поменять чьё то мнение ?
Проблемы в личной жизни?

I>>>Вероятно, твой пример это "я так щитаю"
S>>Вероятно, мне пофигу. Если ты сам не можешь написать такой пример и/или обнаружить в нем перечисленные явления — то это не мои проблемы.

I>Очевдино, это уже обсуждавшаясь ранее тема "эталонов"
Без понятия, о чем ты.

E>>какое это отношение имеет к текущему пользовательскому заказу?
S>Ну, точно такое же, как "сумма стоимостей всех позиций". Её тоже можно посчитать на основе только лишь данных заказа.

одного заказа? конкретного?
а для чего?

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

в Order? возможно. а возможно и не туда. зависит от типа скидки.

E>>он имеет доступ к внутренним коллекциям, а вот должны они быть видны из вне, или нет, зависит от задачи.
S>Вот это интересно. Если у ордера нет public ... Items { get;} — то, конечно же, единственный способ подчитать Total будет реализовать его в ордере.

они видны, но мало ли какую информацию может в себе таить ордер? возможно, мы не хотим раскрывать некоторые детали реализации?

E>>это кто вам сказал что "Неотъемлемой обязанностью Order является только хранить список позиций и прочую информацию о заказе"?
S>Попробуйте отъять у ордера эту обязанность. Что у вас останется?

акцент наверное был на "только".

E>>вы, как и часть здешних, пихаете всё в базу, я правильно понял? тогда позиция определённо ясна.
S>Что именно вы называете "всё"? Да, я рассчитываю хранить заказы в RDBMS.

я имею ввиду логику.

E>>кто же тогда должен считать сумму заказа?
S>Я же уже сказал — что-то вроде OrderUtils.

почему он, а не ордер?

E>>и почему это должен делать кто-то, а не сам заказ, при том что у него для этого есть все необходимые данные?
E>>второй абзац ересь какая-то. вы бы хоть схему нарисовали, или класс накидали. а то выдумали что-то.
S>Спокойнее. Вы же не думаете, что в жизни будет ровно один класс данных с "позициями", и вы назовёте его "Order". Какую схему вы ожидаете? Схему наследования всех этих документов друг от друга? Ну так я вам и объясняю, что внятную схему наследования построить не получится.


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

только в вашем воображении)
по вашему существуют только ДТО и утилиты. вот и пользуйтесь функциональным подходом. я то тут причем?

E>>модель выполняет только свои обязанности.
E>>вышенаписанное ни чем ни лучше. но это только вершина. а как будет расчитываться все остальное в иерархии?
S>Что такое "всё остальное"?

цены, скидки.

S>Вот например — мы только что договорились с производителем DVD-плееров, что будем давать плееры бесплатно при покупке телевизора.

как это относится к логике расчета стоимости заказа?

S>Вас не затруднит привести реализацию метода Product.GetDiscountedPrice(int quantity) для этого случая?
S>И поясните мне ещё раз — я правильно понимаю, что у вас на каждый товар свой класс? То есть для моего случая нужно написать 12000 разных классов? Если нет, то сколько всего наследников мне нужно иметь в иерархии Product?

столько, сколько необходимо. это же просто)

E>>в вашем. все 5 стратегий в 1м методе. на сколько-то десятков строк. добавление/изменение всегда заставит менять этот метод. а это может повлиять на другие его части.
S>С чего вы взяли, что в 1м методе?

значит в 10 переплетенных по каким-то условиям. от этого не легче.

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

добавить скидку на обувь определенного класса?

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

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

S>В реальной жизни сервис был бы устроен примерно так:

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

S>Как видите — ООП в полный рост. Просто объекты не там, где вы привыкли их искать.

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

E>>тоесть вы будете порождать тонные объектов и наделять их не свойственной для них логикой? ради бога.
S>Забавно, но на мой взгляд всё ровно наоборот — это вы порождаете тонны объектов там, где вообще никаких объектов нет (а есть просто данные), и наделяете их совершенно несвойственной им логикой. Но это всё субъективно, так продолжим же объективные рассуждения.

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

E>>только я считаю что нет необходимости порождать ненужные сущности, если у нас уже имеются конкретные объекты, которые мы можем наделить свойственными только им обязанностями.
E>>а если вы считаете что сумма заказа — это не обязанность заказа, ваше дело
S>Рано или поздно вы тоже поймёте, что сумма заказа — не обязанность заказа. Вот вы сходу бросились решать задачу со скидками и угодили в стандартную ловушку. Потому, что вам показалось, что это товар "ведёт себя так" в заказе. Нет! Это не пылесос решает "продайте меня за полцены". Это менеджер принимает решение: "пылесос мы продадим со скидкой 50%, потому что он входит в программу утилизации".

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

S>Далее видно, что менеджер принимает решение не с потолка, а на основе системы правил. В итоге, вместо того, чтобы выполнять анализ в ненужную сторону — "поведения товаров", мы продолжим копать в сторону системы правил. Постараемся выписать все действовавшие когда-либо правила, действующие сейчас, и какие правила планируется применять. Поищем между ними общее, разное. Посмотрим, какие данные нужны правилам, чтобы действовать. И применим всю мощь ООП для моделирования "менеджера", который превратится в DiscountService, и правил. А товары, ордера, строки и прочее так и останутся данными, которыми они и были всю жизнь с 16 примерно века, пока не пришёл Фаулер и не сбил всех с толку.


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

I>То есть, в обязанности продукта входит знание о всех возможных скидках ?

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

I>>>А каким образом менять скидки ? Находить все ордеры, орделайны и тд и модифицировать их до тех пор пока ордер не будет оплачен и закрыт ?
E>>опять нет. но зависит от типа скидок. а сами скидки вполне могут где-то хранится в виде набора правил. в базе, в хмл, в коде.
I>Они так и хранятся и как правила логика этой части меняется очень часто. Каким образом ордер или продукт будет знать, какая стратегия может к ним применяться ?

таким же, как и при реализации с сервисами.

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

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

var total = order.GetTotal();
IProduct delivery = DeliveryService.GetDelivery(total, ..., ...);
order.Add(delivery);

соответственно сервис вернет стоимость доставки 0, если сумма заказов >1000, или 35 грн, если ниже 1000.
при том в заказах мы увидим эту стоимость, а так же увидим изменение общей стоимости заказа, с учетом добавившихся 35 грн.

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

сложности в реализации имелись в виду конечно же но их нет.

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

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

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

S>А чего далеко ходить. WinAPI — в значительной мере ООП. CloseHandle, к примеру, даже полиморфный. В чём вопрос-то?

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

В данном случае квази-OOP достигается не за счет языковых средств, а за счет возможностей/особенностей операционной системы. А хотелось бы примерно так как было обещано на Object Pascal.

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

I>>Ты что, пишешь в форум что бы поменять чьё то мнение ?
S>Проблемы в личной жизни?

Тебе должно быть виднее. Обычно люди обмениваются мнениями, опытом, но вот есть люди которым дай поменять чьё то мнение

E>>ты передёргиваешь.
I>Ты объясни, откуда Ордер будет знать про таблицы валют, скидки, доставки, услуги и тд и тд. Как узнать при оплате заказа, что на момент составления действовала определенная система скидок ?

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

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

так же, как и в сервисе.

>>все эти правила расчета могут быть получены 1 раз при создании объекта Order. а могут быть вообще закешированы на уровне приложения, и доступ к ним будет быстрым при необходимости. для каждой конкретной задачи, своё конкретное решение.
I>Как это будет храниться в базе ? Позиции могут добавляться, удаляться, изменять цену и тд и тд. Как это оформить один раз при создании объекта ордер ?

ORM отлично справляется с этой задачей.

I>Ты же не даёшь внятного ответа.

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

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

я не вижу дублирования. или во всех случаях расчет один и тот же? но это ведь не проблема.

I>>>Поподробнее, как товар/ордер/позиция узнает, что скидка даётся в зависимости от
I>>>1. даты — на НГ каждый второй бесплатный
E>>стратегия?
I>Где хранятся параметры для этой стратегии и где хранится код который обсчитывает её ?

параметры могут быть как в ордере, так и как в сервисе. код в ордере.

I>>>2. времени — за полчаса за закрытие -1%
E>>стратегия?
I>Где хранятся параметры для этой стратегии и где хранится код который обсчитывает её ?

см. выше.

I>>>3. кастомера — постоянным скидка
E>>стратегия?
I>Где хранятся параметры для этой стратегии и где хранится код который обсчитывает её ?

см. выше.

I>>>4. менеджера — менеджер даёт скидку что бы "купить" кастомера
E>>ApplyDiscount? стратегия?
I>Где хранятся параметры для этой стратегии и где хранится код который обсчитывает её ?

см. выше.

I>>>5. полномочий менеджера — "новые менеджеры" не имеют некоторых скидок
E>>так он ничего и не сможет сделать. но это контролируется другим уровнем.
I>То есть, за подсчет цены отвечает какой то другой уровень что ли ?

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

I>>>6. товара — возьми два xxx получи третий бесплатно (например когда в упаковке по три)
E>>в товаре?
I>Я не представляю реализации этой скидки в товаре.

а я представляю. вот и вся разница.

E>>это вообще отдельное полиси. мы будем считать в ордере сумму yyy только когда пользователь их добавит туда. а пока, нас это не волнует и мы это в ордере не делаем. это не его ответственность.
I>Где будет код этой полиси и где будут храниться параметры ?

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

I>>>7. суммарной цены всех товаров (набери товаров на 1000$ )
E>>стратегия?
I>Где хранятся параметры для этой стратегии и где хранится код который обсчитывает её ?

см. выше.

I>>>8. массы заказа (закажи полную корзину и получи доставку бесплатно)
E>>стратегия?
I>Где хранятся параметры для этой стратегии и где хранится код который обсчитывает её ?

см. выше.

I>>>9. адрес доставки (доставка по району zzz бесплатна)
E>>стратегия?
I>Где хранятся параметры для этой стратегии и где хранится код который обсчитывает её ?

см. выше.

I>>>... — продолжать можно до бесконечности. Ты все это хочешь хранить в ордере что ли ?
E>>ты сам придумал что я этого хочу. а я ведь такого не говорил.
I>Я привел тебе реальный пример. Это не я придумал, а требования бизнеса.

ты сам придумал что я все это хочу хранить в ордере. если тебе так понятнее.

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

I>Для того, что бы хотя бы разобраться с тем как работают скидки и внести изменения, придется мотаться по совершенно разным частям приложеня
I>Между тем код этих скидок меняется очень часто, потому логично хранить его в одном месте, скажем DiscountService или наборе таких сервисов, а параметры подтягивать из базы.

все то же самое как и сервисами. и из базы параметры подтягиваются. и мотаться по коду так же как с кучей сервисов.

E>>мы ему об этом сообщим. а возможно он и сам знает. ведь есть полиси скидок для каждого продукта? вот продукт эти полиси, логично, может видеть.
I>То есть, GetTotal у Order будет видеть все классы участников и все полиси всех классов участников ?

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

I>>>Все стратегии будут в разных методах Выбор делается в зависимости от состава участников.
E>>то же самое и тут.
I>А что делать при изменении детализации, например в случае изменений той части базы про товары, доставки придется перепахивать код ордеров

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

I>Я говорю о том, скидки могут быть применены гораздо шире, чем только с заказами. С возвратами что, придется выписывать специальную логику которая аналогично заказам ? Или наследовать возврат от заказа ?

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

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

I>>Вообще говоря идентичность уже включено в понятие messaging

L>Ошибаешься.

Ваш пост был очень глубок и убедтелен, он в корне перевернул представления всей индустрии о то, что такое ооп. Аргумент "Ошибаешься" мне показался особенно блистательным.
Пишите исчо.
Несомненно, RSDN.Lloyd туфты не напишет

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

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

I>>>Ты что, пишешь в форум что бы поменять чьё то мнение ?
S>>Проблемы в личной жизни?

I>Тебе должно быть виднее. Обычно люди обмениваются мнениями, опытом, но вот есть люди которым дай поменять чьё то мнение

Меня поражает, как можно прийти к такому выводу из утверждения о том что мне чихать на твое мнение? И, кстати, обмен мнениями и опытом — это не про тебя. Чужие мнения и опыт интересуют тебя только как предмет для дискредитации любыми средствами, вплоть до подтасовки цитат. О чем тебе только в этом топике неоднократно уже писали.

Здравствуйте, мыщъх, Вы писали:

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

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

T>>Но не вздумайте сделать проще чем надо.
М>+100500

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


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

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

E>ордеру ничего на себе завязывать не придется. абстрактный пример может выглядеть так:

E>

E>var total = order.GetTotal();
E>IProduct delivery = DeliveryService.GetDelivery(total, ..., ...);
E>order.Add(delivery);
E>

А как быть если какая то позиция была удалена, отредактирована, добавлена, надо повторить такие действия ?

Ты похоже показал, что order.GetTotal будет зависеть от стоимости доставки, а стоимост доставки будет зависеть от стоимости заказа

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

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

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

E>>>это кто вам сказал что "Неотъемлемой обязанностью Order является только хранить список позиций и прочую информацию о заказе"?
S>>Попробуйте отъять у ордера эту обязанность. Что у вас останется?
E>акцент наверное был на "только".
SRP предполагает, что обязанность ровно одна. Если мы нашли одну неотъемлемую, значит остальные — отъемлемые.

E>я имею ввиду логику.
Я практик. Видите ли, крайне сложно порвать SQL на операциях вида update orderLine set quantity = quantity + 1 при помощи операций в middle-tier. Поэтому для меня хороша та архитектура, которая хотя бы в теории позволяет построить запрос в middle tier, а потом спустить его в SQL и забыть.

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

E>только в вашем воображении)
E>по вашему существуют только ДТО и утилиты. вот и пользуйтесь функциональным подходом. я то тут причем?

S>>Вот например — мы только что договорились с производителем DVD-плееров, что будем давать плееры бесплатно при покупке телевизора.
E>как это относится к логике расчета стоимости заказа?
Это и есть "расчёт стоимости заказа". В заказе две позиции — телевизор за 17000 и плеер за 2100. Сумма заказа — 17000, потому что плеер должен идти бесплатно. Если я купил только плеер — 2100. Два плеера — 4200.

E>столько, сколько необходимо. это же просто)
Очевидно, что необходимо ровно 0, т.к. задачу можно решить вообще без наследников класса продукт. И без класса как такового, т.к. его обязанности прекрасно выполнит struct.

E>значит в 10 переплетенных по каким-то условиям. от этого не легче.
Почему в 10 переплетённых? Почему вы не читаете то, что я вам пишу?

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

E>за тем же, зачем вы фантазируете монолитную реализацию ордера
Я не фантазирую монолитной реализации.

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

E>все это отлично кладётся в ордер, где имхо ему и место. но вы в праве думать иначе.
Что именно "всё"? Логика по расчёту скидок? А почему в Order, а не в, скажем, Customer?
Ничего отличного в этом нету. Поясняю: логика расчёта скидок сегодня одна, а завтра другая.
Это я параноидально написал тут пять классов правил, и последовательность применения. А в жизни — одна кофейня даёт 50% скидку при заказе "на вынос", а другая только накапливает бонусы на карту. Им нафиг не упёрлись все эти иерархии, рабочее место конфигуратора системы и редактор календаря действия скидок.

В системе, написанной в моём подходе, достаточно заменить реализацию IDiscountService — а всё остальное останется работать. Гарантированно.
Потому что сами заказы в обеих кофейнях устроены совершенно одинаково.
В вашем подходе логика расчёта запихана в сам класс Order. Любое изменение там — это перетестирование класса, и всех зависимых от него классов.

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

E>я не буду спорить, что применимо к интернет магазину, ООП подход как таковой, в частности ДДД, который тут неоднократно упоминали, лучше, нежели анемик. но в то же время я уверен что и рич модель будет эффективной.
Ещё раз поясню, что подход, который я описываю — это ООП. Все черты ООП в нём в полный рост. Для микромагазинов на 5 товаров действительно можно оперировать рич моделью.
Как только вы попробуете построить настоящую систему уровня хотя бы сети магазинов "аскания", ваша rich упрётся в чудовищные проблемы.

Вам просто почему-то кажется, что ООП — это значит запихать методы в данные. Даже если у моделируемых объектов в доменной области не было никакого поведения, которым вы их наделяете. А я вижу, что в решении задач "активных" сущностей, достойных быть объектами, значительно меньше, чем "пассивных" сущностей, от которых нужны только данные.
В учётных задачах ООП вообще порой страшно вредит.

E>это не изменит реализации. мы установим на товар скидку, а Order.GetTotal() в данном случаи не изменится но вернет правильную сумму.
E>у нас проблема в том, что мы оперируем разными понятиями и не можем понять друг друга.
Каким образом вы "установите на товар скидку"? Может быть, вы наконец попытаетесь написать пример кода?
Вы упоминали пять классов продуктов с уникальными скидочными стратегиями. Приведите хотя бы два.

E>если это работает, и работает так, как нужно, это здорово, и нет необходимости что-то менять.
E>я бы пошел по другому пути. лучше, хуже, не знаю.
E>но раз появился Фаулер со своей идеологией, и её подхватили, значит есть и для них свои задачи
Это интересный вывод. Я вот вижу, что вы подхватили идеологию Фаулера, но при этом искренне пытаетесь её применять в неподходящих задачах. И таких людей, как показывает практика, большинство. Вы всё же постарайтесь критически относиться к Фаулеру, и задумываться, зачем вы принимаете то или иное решение.

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

I>Я собственно и ждал похожего примера. Хочется узнать что такое "в значительной мере ООП", т.к. этой фразой подразумевается, что ООП не совсем полноценный.
Не все вызовы из WinAPI ведут себя как методы объектов.

I>В данном случае квази-OOP достигается не за счет языковых средств, а за счет возможностей/особенностей операционной системы. А хотелось бы примерно так как было обещано на Object Pascal.
А какая разница, на Object Pascal или нет? Залудить CreateFile/FileRead/FileWrite/CloseHandle можно хоть на Visual Basic, хоть на виртовском паскале.
Дело же не в языке, а в том, как устроено решение.

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

I>Несомненно, RSDN.Lloyd туфты не напишет

I>

Рекомендую те же самые слова примерить к себе.

Удачи, мой смешливый друг.

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

E>ну что за глупости опять? мы спросим у продукта его цену с учетом необходимых условий, и продукт нам её вернет.
Код вот этого вот "спросим у продукта" — в студию. Без этого все аргументы, простите, ничего не стоят.

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

I>>Тебе должно быть виднее. Обычно люди обмениваются мнениями, опытом, но вот есть люди которым дай поменять чьё то мнение

S>Меня поражает, как можно прийти к такому выводу из утверждения о том что мне чихать на твое мнение?

Я пришел к таком выводу исходя вот из твоих ассоциаций "А то что? А то ты останешься при своем мнении?"

>И, кстати, обмен мнениями и опытом — это не про тебя. Чужие мнения и опыт интересуют тебя только как предмет для дискредитации любыми средствами,

Чужие мнения меня интересуют как ещё одна точка зрения. Предмет для дискредитации это отказ от прояснения своей точки зрения. Не совсем ясно, чего ты делаешь на профильном форуме, если отказываешься прояснить свою точку зрения

>вплоть до подтасовки цитат. О чем тебе только в этом топике неоднократно уже писали.

Только не мне, а тебе. Могу с цитатами, где некто(не я), указывает на передёргивания с твоей стороны

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

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

E>>ордеру ничего на себе завязывать не придется. абстрактный пример может выглядеть так:

E>>

E>>var total = order.GetTotal();
E>>IProduct delivery = DeliveryService.GetDelivery(total, ..., ...);
E>>order.Add(delivery);
E>>

I>А как быть если какая то позиция была удалена, отредактирована, добавлена, надо повторить такие действия ?

ничего сложного.

order.SetDelivery(new DeliveryStrategy());

а order.GetTotal будет содержать приблизительно следующий код

var total = Sum(this.orderLines.GetCost());
return total + this.Delivery.GetCost(total);

соответственно GetTotal всегда вернет актуальную цену.

I>Ты похоже показал, что order.GetTotal будет зависеть от стоимости доставки, а стоимост доставки будет зависеть от стоимости заказа

оно ведь так в жизни и есть. правда?

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

>>вплоть до подтасовки цитат. О чем тебе только в этом топике неоднократно уже писали.

I>Только не мне, а тебе.

Тебе, Павел, тебе.

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

E>

E>var total = order.GetTotal();
E>IProduct delivery = DeliveryService.GetDelivery(total, ..., ...);
E>order.Add(delivery);
E>

Ну вот и отлично. Видим, что за доставку отвечает DeliveryService. За скидки — DiscountService.
Осталось понять, зачем вписывать GetTotal внутрь класса Order, когда с точки зрения удобства поддержки гораздо проще сделать его extension-методом.

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

L>Ошибаешься
Вообще-то нет. Кей напрямую идентичность не упоминает, но его messaging подразумевает возможность послать сообщение конкретному объекту, вне зависимости от его состояния. Так что без identity messaging не работает.

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

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

S>>Меня поражает, как можно прийти к такому выводу из утверждения о том что мне чихать на твое мнение?

I>Я пришел к таком выводу исходя вот из твоих ассоциаций "А то что? А то ты останешься при своем мнении?"
Точно, я в пылу высказал свои самые серьезные опасения...

>>И, кстати, обмен мнениями и опытом — это не про тебя. Чужие мнения и опыт интересуют тебя только как предмет для дискредитации любыми средствами,

I>Чужие мнения меня интересуют как ещё одна точка зрения. Предмет для дискредитации это отказ от прояснения своей точки зрения. Не совсем ясно, чего ты делаешь на профильном форуме, если отказываешься прояснить свою точку зрения
Я не желаю потратить на это месяц. А в твоем случае, меньшим, похоже не обойтись.

>>вплоть до подтасовки цитат. О чем тебе только в этом топике неоднократно уже писали.

I>Только не мне, а тебе. Могу с цитатами, где некто(не я), указывает на передёргивания с твоей стороны
Это писали мне? Я как-то не подумал об этом, т.к. это были ответы на твои сообщения.