Здравствуйте, Enomay, Вы писали:
E>ничего сложного.
E>order.SetDelivery(new DeliveryStrategy());
E>а order.GetTotal будет содержать приблизительно следующий код
E>var total = Sum(this.orderLines.GetCost()); E>return total + this.Delivery.GetCost(total);
E>соответственно GetTotal всегда вернет актуальную цену.
А как со скидками быть ? Хочется в эту схему вписать и скидки, но я не понимаю, как это сделать используя твой дизайн.
I>>Ты похоже показал, что order.GetTotal будет зависеть от стоимости доставки, а стоимост доставки будет зависеть от стоимости заказа
E>оно ведь так в жизни и есть. правда?
Здравствуйте, Sinclair, Вы писали:
L>>Ошибаешься S>Вообще-то нет. Кей напрямую идентичность не упоминает, но его messaging подразумевает возможность послать сообщение конкретному объекту, вне зависимости от его состояния. Так что без identity messaging не работает.
Здравствуйте, Sinclair, Вы писали:
I>>В данном случае квази-OOP достигается не за счет языковых средств, а за счет возможностей/особенностей операционной системы. А хотелось бы примерно так как было обещано на Object Pascal. S>А какая разница, на Object Pascal или нет? Залудить CreateFile/FileRead/FileWrite/CloseHandle можно хоть на Visual Basic, хоть на виртовском паскале. S>Дело же не в языке, а в том, как устроено решение.
E>>в Order? возможно. а возможно и не туда. зависит от типа скидки. S>То есть вы предлагаете размазать обязанности расчёта скидок по нескольким различным классам модели. Простите, но мне это не кажется хорошей идеей.
очень странно, так как идея размазывания по разным классам сервисов вам кажется хорошей идеей.
E>>они видны, но мало ли какую информацию может в себе таить ордер? возможно, мы не хотим раскрывать некоторые детали реализации? S>Ну я же вас сразу спросил — есть ли какая-то непубличная информация, нужная для расчёта стоимости. Если стоимость не зависит от деталей реализации, то ничего раскрывать и не нужно.
я могу предположить, но сказать точно, не имея всех требований, увы.
E>>акцент наверное был на "только". S>SRP предполагает, что обязанность ровно одна. Если мы нашли одну неотъемлемую, значит остальные — отъемлемые.
по-вашему у ордера задача только одна — хранить данные? интересное понимание ответственности. но пусть будет так.
E>>я имею ввиду логику. S>Я практик. Видите ли, крайне сложно порвать SQL на операциях вида update orderLine set quantity = quantity + 1 при помощи операций в middle-tier. Поэтому для меня хороша та архитектура, которая хотя бы в теории позволяет построить запрос в middle tier, а потом спустить его в SQL и забыть.
это ваше дело. тут спорить смысла нет. в интернете все давно разжевано.
E>>почему он, а не ордер? S>Потому что это улучшает архитектуру. Ордер выполняет меньше обязанностей (SRP), его проще написать и протестировать, код расчёта суммы проще написать и протестировать, он надёжнее, его можно повторно использовать для любых Order-like структур.
от того, что метод находится не в ордере, а в сервисе, ни метод, ни ордер, проще не становится.
в вашем случаи все методы работают только с внешними данными, у меня с внутренними. это решит проблему "закрытости", при необходимости.
S>>>Вот например — мы только что договорились с производителем DVD-плееров, что будем давать плееры бесплатно при покупке телевизора. E>>как это относится к логике расчета стоимости заказа? S>Это и есть "расчёт стоимости заказа". В заказе две позиции — телевизор за 17000 и плеер за 2100. Сумма заказа — 17000, потому что плеер должен идти бесплатно. Если я купил только плеер — 2100. Два плеера — 4200.
ну и отлично. если купили телевизор, то плеер добавляется к ордеру с ценой 0. ордер вернет стоимость 17000. иначе цена будет другой.
E>>значит в 10 переплетенных по каким-то условиям. от этого не легче. S>Почему в 10 переплетённых? Почему вы не читаете то, что я вам пишу?
потому что вы не читаете то, что я пишу.
E>>добавить скидку на обувь определенного класса? S>Конкретнее можно? Какие классы у нас были в модели до того, как появилась такая скидка? Какие классы изменились? Какие классы появились?
в объектной модели у нас ничего не изменилось. добавили товару в базе скидку и забыли. Ордер вернет правильную сумму заказа.
E>>более того, на ордер у вас рапспространяется даже то, чего там быть не должно. а ведь это всего лишь заказ. S>Например чего в ордере быть не должно?
все то, что вы ему приписали, кроме расчета общей стоимости заказа
E>>все это отлично кладётся в ордер, где имхо ему и место. но вы в праве думать иначе. S>Что именно "всё"? Логика по расчёту скидок? А почему в Order, а не в, скажем, Customer?
наверное потому, что общая сумма заказа есть информация о самом заказе и относящаяся к нему?
S>Ничего отличного в этом нету. Поясняю: логика расчёта скидок сегодня одна, а завтра другая. S>Это я параноидально написал тут пять классов правил, и последовательность применения. А в жизни — одна кофейня даёт 50% скидку при заказе "на вынос", а другая только накапливает бонусы на карту. Им нафиг не упёрлись все эти иерархии, рабочее место конфигуратора системы и редактор календаря действия скидок.
разве я против? делайте как вам удобнее
S>В системе, написанной в моём подходе, достаточно заменить реализацию IDiscountService — а всё остальное останется работать. Гарантированно. S>Потому что сами заказы в обеих кофейнях устроены совершенно одинаково. S>В вашем подходе логика расчёта запихана в сам класс Order. Любое изменение там — это перетестирование класса, и всех зависимых от него классов.
глупости. а говорите что я не читаю ваши сообщения. а я ведь писал, что ордер кроме суммирования, фактически ничего не делает.
E>>вот вот. просто я храню реализацию не там, где вы. она от этого несколько меняется, но хуже не становится. S>Ну почему же "не становится". Ещё как становится. Производительность — ниже, стоимость внесения изменений — выше.
очень спорное и беспредметное утверждение.
E>>я не буду спорить, что применимо к интернет магазину, ООП подход как таковой, в частности ДДД, который тут неоднократно упоминали, лучше, нежели анемик. но в то же время я уверен что и рич модель будет эффективной. S>Ещё раз поясню, что подход, который я описываю — это ООП. Все черты ООП в нём в полный рост. Для микромагазинов на 5 товаров действительно можно оперировать рич моделью.
в ООП так же входит то, что объект оперирует внутренним состоянием. у вас состояние и действия разнесены в разные места.
S>Как только вы попробуете построить настоящую систему уровня хотя бы сети магазинов "аскания", ваша rich упрётся в чудовищные проблемы.
я думаю это проблема не в рич подходе.
S>Вам просто почему-то кажется, что ООП — это значит запихать методы в данные. Даже если у моделируемых объектов в доменной области не было никакого поведения, которым вы их наделяете. А я вижу, что в решении задач "активных" сущностей, достойных быть объектами, значительно меньше, чем "пассивных" сущностей, от которых нужны только данные. S>В учётных задачах ООП вообще порой страшно вредит.
мне кажется что для каждой задачи существует своё решение. а выбирать нужно из того, что лучше умеешь. я не сталкивался с конкретно вашими проблемами, но сталкивался с проблемами которые возникают от подобного подхода к реализации.
особенно — логика в базе. но это все лирика.
E>>это не изменит реализации. мы установим на товар скидку, а Order.GetTotal() в данном случаи не изменится но вернет правильную сумму. E>>у нас проблема в том, что мы оперируем разными понятиями и не можем понять друг друга. S>Каким образом вы "установите на товар скидку"? Может быть, вы наконец попытаетесь написать пример кода?
в базе установлю. так же как и вы.
E>>если это работает, и работает так, как нужно, это здорово, и нет необходимости что-то менять. E>>я бы пошел по другому пути. лучше, хуже, не знаю. E>>но раз появился Фаулер со своей идеологией, и её подхватили, значит есть и для них свои задачи S>Это интересный вывод. Я вот вижу, что вы подхватили идеологию Фаулера, но при этом искренне пытаетесь её применять в неподходящих задачах. И таких людей, как показывает практика, большинство. Вы всё же постарайтесь критически относиться к Фаулеру, и задумываться, зачем вы принимаете то или иное решение.
я не вижу ничего плохого в решении задач вашим способом. если он вам ближе, то не стоит заморачиваться.
на сегодняшний день я не вижу ничего плохого в рич модели. она хорошо справляется с моими задачами. а это увы, не интернет магазины.
и в моем случае код получается достаточно логичный и структурированный.
это касается реализации БЛ. где нужно будет анемик модель, будет анемик (в основном отображение данных).
E>>ну что за глупости опять? мы спросим у продукта его цену с учетом необходимых условий, и продукт нам её вернет. S>Код вот этого вот "спросим у продукта" — в студию. Без этого все аргументы, простите, ничего не стоят.
product.GetPrice() ?
при необходимости в этот метод можно передать еще что-то. например кол-во этих продуктов в заказе. от этого изменится возвращемое значение.
S>Ну вот и отлично. Видим, что за доставку отвечает DeliveryService. За скидки — DiscountService. S>Осталось понять, зачем вписывать GetTotal внутрь класса Order, когда с точки зрения удобства поддержки гораздо проще сделать его extension-методом.
вам проще? удобнее? делайте
а я его засуну в Ордер, что бы не плодить лишний класс с единственным методом.
и с точки зрения удобства я не вижу недостатков.
E>>var total = Sum(this.orderLines.GetCost()); E>>return total + this.Delivery.GetCost(total);
E>>соответственно GetTotal всегда вернет актуальную цену. I>А как со скидками быть ? Хочется в эту схему вписать и скидки, но я не понимаю, как это сделать используя твой дизайн.
зависит от типа скидки. если она на конкретный товар, то изменим его полиси скидки в базе на этот товар. если вообще, от внешних значений, применим стратегию к total в этом методе.
I>>>Ты похоже показал, что order.GetTotal будет зависеть от стоимости доставки, а стоимост доставки будет зависеть от стоимости заказа E>>оно ведь так в жизни и есть. правда? I>Я говорил про депенденсы, а не про результат.
модель отражает жизненную ситуацию. это правильно.
Здравствуйте, samius, Вы писали:
I>>Чужие мнения меня интересуют как ещё одна точка зрения. Предмет для дискредитации это отказ от прояснения своей точки зрения. Не совсем ясно, чего ты делаешь на профильном форуме, если отказываешься прояснить свою точку зрения S>Я не желаю потратить на это месяц. А в твоем случае, меньшим, похоже не обойтись.
Можешь не тратить месяц — Синклер сделал то о чем я тебя просил всего за одно сообщение. Тренируйся.
Здравствуйте, Enomay, Вы писали:
E>зависит от типа скидки. если она на конкретный товар, то изменим его полиси скидки в базе на этот товар. если вообще, от внешних значений, применим стратегию к total в этом методе.
А если GetTotal считать во внешнем, по отношению к Order, сервисе, то у нас только одно место безо всяких если, при чем эта часть какправило меняется очень часто и не надо будет приседать в будущем.
I>>>>Ты похоже показал, что order.GetTotal будет зависеть от стоимости доставки, а стоимост доставки будет зависеть от стоимости заказа E>>>оно ведь так в жизни и есть. правда? I>>Я говорил про депенденсы, а не про результат.
E>модель отражает жизненную ситуацию. это правильно.
Качественная модель отражать способ которым резолвится циклическая зависимость, а не само наличие этой зависимости.
E>>зависит от типа скидки. если она на конкретный товар, то изменим его полиси скидки в базе на этот товар. если вообще, от внешних значений, применим стратегию к total в этом методе. I>А если GetTotal считать во внешнем, по отношению к Order, сервисе, то у нас только одно место безо всяких если, при чем эта часть какправило меняется очень часто и не надо будет приседать в будущем.
совершенно не обязательно. иногда может оказать наоборот.
проще говоря, где бы GetTotal не находился, сложность его модификации от этого слабо меняется.
Здравствуйте, Enomay, Вы писали:
E>совершенно не обязательно. иногда может оказать наоборот. E>проще говоря, где бы GetTotal не находился, сложность его модификации от этого слабо меняется.
Наоборот В большинстве случаев его вообще не нужно будет модифицировать, а если поместить код в Ордер, придется обкладывать все случаи if/else
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Sinclair, Вы писали:
L>>>Ошибаешься S>>Вообще-то нет. Кей напрямую идентичность не упоминает, но его messaging подразумевает возможность послать сообщение конкретному объекту, вне зависимости от его состояния. Так что без identity messaging не работает.
L>т.е. SOA — это ООП? Или SOA — это не messaging?
Как в SOA же нет состояния.
Нет состояния — нет ООП.
Нет ножек — нет мультиков.
Здравствуйте, Flem1234, Вы писали:
S>>>Вообще-то нет. Кей напрямую идентичность не упоминает, но его messaging подразумевает возможность послать сообщение конкретному объекту, вне зависимости от его состояния. Так что без identity messaging не работает.
L>>т.е. SOA — это ООП? Или SOA — это не messaging?
F>Как в SOA же нет состояния. F>Нет состояния — нет ООП. F>Нет ножек — нет мультиков.
О том и речь, что утверждение "идентичность уже включено в понятие messaging", мягко говоря, сомнительно.
Здравствуйте, Lloyd, Вы писали:
S>>>>Вообще-то нет. Кей напрямую идентичность не упоминает, но его messaging подразумевает возможность послать сообщение конкретному объекту, вне зависимости от его состояния. Так что без identity messaging не работает.
F>>Как в SOA же нет состояния. F>>Нет состояния — нет ООП.
L>О том и речь, что утверждение "идентичность уже включено в понятие messaging", мягко говоря, сомнительно.
Здравствуйте, Flem1234, Вы писали:
L>>О том и речь, что утверждение "идентичность уже включено в понятие messaging", мягко говоря, сомнительно.
F>А как возможно отослать сообщение без адресата?
Здравствуйте, Ikemefula, Вы писали:
L>>Вызов процедуры, например.
I>Где же здесь messaging т.е. взаимодействие объектов через посылку-приём сообщений ?
Посылка сообщения — это абстракция любого вызова, не только вызова методов объектов. Для примера, можешь поинтересоваться SOA и очередями сообщений.
