ну об этом в посте и речь, что это такая фундаментальная вещь что описывать ее в каком-то ёба-принципе смысла 0

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

именно

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

Зашло))

таких принципов можно сочинить на страницу

@yegor256 идейку подкинули: написать компилятор, который будет конструкцию объектов заменяьт вызовами функций. Можно будет писать на тру ооп, не насилуя ГЦ

@yegor256 идейку подкинули: написать компилятор, который будет конструкцию объектов заменяьт вызовами функций. Можно будет писать на тру ооп, не насилуя ГЦ

Растолкуй, интересно

@yegor256 идейку подкинули: написать компилятор, который будет конструкцию объектов заменяьт вызовами функций. Можно будет писать на тру ооп, не насилуя ГЦ

У меня аналогичная идейка возникала, и я даже работал над ней. Муторно. Непонятно что делать с методами возвращающими и принимающими объекты.

@yegor256 идейку подкинули: написать компилятор, который будет конструкцию объектов заменяьт вызовами функций. Можно будет писать на тру ооп, не насилуя ГЦ

я тож не особо понял, объясни плз

У меня аналогичная идейка возникала, и я даже работал над ней. Муторно. Непонятно что делать с методами возвращающими и принимающими объекты.

По логике один вызов на композите в EO стиле можно разложить в одну баааальшуую процедуру, избежав при этом ненужных аллокаций. Но это придется делать для любого клиентского вызова. Для каждого entry pointа. И такие процедуры будут совсем не реюзабл

То есть это применимо для приложений (где entry point это main), а вот для библиотек четкактонеочень

@yegor256 идейку подкинули: написать компилятор, который будет конструкцию объектов заменяьт вызовами функций. Можно будет писать на тру ооп, не насилуя ГЦ

У тебя глагол пропущен, не понимаю, будет делать конструкцию?

кстати как там EO? проект уже закрылся?

У тебя глагол пропущен, не понимаю, будет делать конструкцию?

глагол "заменять"

кстати как там EO? проект уже закрылся?

Егор вон объявил, что над 3-м томом работает

я про язык

То есть это применимо для приложений (где entry point это main), а вот для библиотек четкактонеочень

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

https://github.com/yegor256/eo

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

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

И должна оставаться возможность добавить ещё поведения

А ещё наш мир не идеален, в нём много условий и краевых случаев, которые приходится отражать в коде

И должна оставаться возможность добавить ещё поведения

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

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

Я хочу понять общий принцип, а не решение конкретной задачи в вакууме.

А общий принцип такой что когда вы говорите "добавить еще поведения" в объект - это уже нарушение SRP, OCP и скорее всего ISP.

Впринципе так обычно с сервисами и поступают. Нужен новый функционал - берем какой нить из сервисов, и лабаем там новый метод.

Однако вот тебе конкретный пример. Человек покупает подписку на сервис в интернет магазине, и при этом может выбрать за какой период будет платить, и чем больше период тем больше скидка. Однако у человека могут быть ещё и персональные скидки, а также купоны с акций. Как оформить расчёт цены за сервис в конце выбранного биллинг периода?

Однако вот тебе конкретный пример. Человек покупает подписку на сервис в интернет магазине, и при этом может выбрать за какой период будет платить, и чем больше период тем больше скидка. Однако у человека могут быть ещё и персональные скидки, а также купоны с акций. Как оформить расчёт цены за сервис в конце выбранного биллинг периода?

Ок. Щас будет

пф СкидкаИнтерфейс, собираем всех возможных, пихаем в СкидкаКалькулятор .... PROFIT

изи

забыл абстрактную скидку

и фабрику скидок

и фабрику скидок

абстрактную

ну это же очевидно

Без обсервера скидок никуда жи

и ПРЕ/ПОСТ процессинга тоже

и все это в аннотацию @Скидка запихать

и все это в аннотацию @Скидка запихать

Слишком просто

Приёмочные тесты не пройдет

мои пройдет) я уж постраюсь

Однако вот тебе конкретный пример. Человек покупает подписку на сервис в интернет магазине, и при этом может выбрать за какой период будет платить, и чем больше период тем больше скидка. Однако у человека могут быть ещё и персональные скидки, а также купоны с акций. Как оформить расчёт цены за сервис в конце выбранного биллинг периода?

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

а если скидки независимы, то банальный фолдл

этож прям по паттернам ОО проектирования банды четырех)

Ок. Щас будет

Цель - посчитать цену. Заводим интерфейс - Цена. Методы - значение() и валюта(). Первая имплементация - фейк. В конструкторе цена и валюта, методы возвращают то что в конструкторе. Далее - ЦенаСУчетомСкидки(Цена, скидка). В конструкторе цена и размер скидки. Методы высчитывают цену с учетом скидки. Далее - купоны. Про купоны инфы в примере недостаточно но скорее всего это отдельный интерфейс Купон. Какие там методы - зависит от того как купон может влиять на итоговую цену. ЦенаСУчетомКупона(Цена, Купон). И наконец ИсходнаяЦенаПродукта(ИД_продукта), который извлечет цену из (базы/другогосервиса).

мне кажется синтаксис очень тяжелым у них

а ты понимаешь, что в ЯП смотреть на синтаксис — последнее дело? (он не играет никакой роли)

этож прям по паттернам ОО проектирования банды четырех)

падажжи, тут не хватает тогда как минимум бриджа и визитора

Цель - посчитать цену. Заводим интерфейс - Цена. Методы - значение() и валюта(). Первая имплементация - фейк. В конструкторе цена и валюта, методы возвращают то что в конструкторе. Далее - ЦенаСУчетомСкидки(Цена, скидка). В конструкторе цена и размер скидки. Методы высчитывают цену с учетом скидки. Далее - купоны. Про купоны инфы в примере недостаточно но скорее всего это отдельный интерфейс Купон. Какие там методы - зависит от того как купон может влиять на итоговую цену. ЦенаСУчетомКупона(Цена, Купон). И наконец ИсходнаяЦенаПродукта(ИД_продукта), который извлечет цену из (базы/другогосервиса).

Если появляется новый аргумент в ценообразовании, то это - новая имплементация интерфейса Цена.

А вот вопрос сирозный - а кто-нибудь пользовался rest-assured?

Цель - посчитать цену. Заводим интерфейс - Цена. Методы - значение() и валюта(). Первая имплементация - фейк. В конструкторе цена и валюта, методы возвращают то что в конструкторе. Далее - ЦенаСУчетомСкидки(Цена, скидка). В конструкторе цена и размер скидки. Методы высчитывают цену с учетом скидки. Далее - купоны. Про купоны инфы в примере недостаточно но скорее всего это отдельный интерфейс Купон. Какие там методы - зависит от того как купон может влиять на итоговую цену. ЦенаСУчетомКупона(Цена, Купон). И наконец ИсходнаяЦенаПродукта(ИД_продукта), который извлечет цену из (базы/другогосервиса).

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

и валюта тут — перпендикулярна, не надо сюда примешивать

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

Я дал черновой вариант. Не буду же я здесь CRM целиком расписывать. Как этот подход мешает их комбинировать?

Я дал черновой вариант. Не буду же я здесь CRM целиком расписывать. Как этот подход мешает их комбинировать?

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

Добрый день. Вот вместо зарезервированного ключевого слова class используют -> clazz для название переменной. Я такое часто видел и думаю, что это уже что-то вроде конвенции. А есть ли еще конвенции для других ключевых слов? Хотел назвать переменную default, но не смог по понятным причинам, пришлось назвать $default ?

(в общем случае)

Добрый день. Вот вместо зарезервированного ключевого слова class используют -> clazz для название переменной. Я такое часто видел и думаю, что это уже что-то вроде конвенции. А есть ли еще конвенции для других ключевых слов? Хотел назвать переменную default, но не смог по понятным причинам, пришлось назвать $default ?

def?

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

А где я сказал что в коненом итоге имеются данные об одной скидке?

cls?

А где я сказал что в коненом итоге имеются данные об одной скидке?

например, ЦенаСУчетомКупона(Цена, Купон), в интерфейсе СкидкаИнтерфейс

короче, я б такое и близко не аппрувнул

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

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

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

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

берешь все-все (все виды имеющихся скидкок), запихиваешь в специальный метод, и он считает

Цель - посчитать цену. Заводим интерфейс - Цена. Методы - значение() и валюта(). Первая имплементация - фейк. В конструкторе цена и валюта, методы возвращают то что в конструкторе. Далее - ЦенаСУчетомСкидки(Цена, скидка). В конструкторе цена и размер скидки. Методы высчитывают цену с учетом скидки. Далее - купоны. Про купоны инфы в примере недостаточно но скорее всего это отдельный интерфейс Купон. Какие там методы - зависит от того как купон может влиять на итоговую цену. ЦенаСУчетомКупона(Цена, Купон). И наконец ИсходнаяЦенаПродукта(ИД_продукта), который извлечет цену из (базы/другогосервиса).

Как параметризуется тип скидки? Что, если к цене применяется несколько скидок? Допустим, что купон это тоже скидка с фиксированной ценой, которая действует один раз и не должна применяться при рекарринге (втором и последующих расчётах цены в конце периода).

а у кого этот метод?

Как параметризуется тип скидки? Что, если к цене применяется несколько скидок? Допустим, что купон это тоже скидка с фиксированной ценой, которая действует один раз и не должна применяться при рекарринге (втором и последующих расчётах цены в конце периода).

@yegor256 А ты что скажешь о предложенном решении?

а у кого этот метод?

да пофиг сделай, к примеру, object Discount, и у него def calculateAllDiscounts(original: Item, discounts: Seq[Discount]): BigDecimal

ERROR: S client not available

Как параметризуется тип скидки? Что, если к цене применяется несколько скидок? Допустим, что купон это тоже скидка с фиксированной ценой, которая действует один раз и не должна применяться при рекарринге (втором и последующих расчётах цены в конце периода).

Купон - это контракт, откуда он взялся и как он повлияет на цену зависит от его имплементации.

Купон - это контракт, откуда он взялся и как он повлияет на цену зависит от его имплементации.

То есть мы получаем объект ЦенаСоСкидкойИКупоном?

да пофиг сделай, к примеру, object Discount, и у него def calculateAllDiscounts(original: Item, discounts: Seq[Discount]): BigDecimal

то есть если это перевести на джаву, то у класса Discount будет статический метод calculateAllDiscounts(Item original, Stream<Discount> discounts)?

то есть если это перевести на джаву, то у класса Discount будет статический метод calculateAllDiscounts(Item original, Stream<Discount> discounts)?

да, только не Stream, а List

только лучше бы его назвать totalPrice

То есть мы получаем объект ЦенаСоСкидкойИКупоном?

Почему? Зачем нам это если есть ЦенаСоСкидкой, ЦенаСКупоном и композиция?

да, только не Stream, а List

зачем нам лист?

зачем нам лист?

а почему нет?

что-то итерируемое надо

а почему нет?

зачем упорядочивание и доступ в середину по индексу

что-то итерируемое надо

вот именно

Почему? Зачем нам это если есть ЦенаСоСкидкой, ЦенаСКупоном и композиция?

Не - замутить конечно можно если сильно хочется например матрешку сократить

Почему? Зачем нам это если есть ЦенаСоСкидкой, ЦенаСКупоном и композиция?

А как будет выглядеть эта композиция? И что должно именно композироваться? По факту, цена только одна, меняется только набор модификаторов к ней

А как будет выглядеть эта композиция? И что должно именно композироваться? По факту, цена только одна, меняется только набор модификаторов к ней

Цена одна для простейшего примера. На самом деле там всё хуже конечно, но это потом

зачем упорядочивание и доступ в середину по индексу

упорядочивание? доступ в середину, для List, не гарантирует константы же

ну тоже пофиг, я просто не знаю, что такое Stream

упорядочивание? доступ в середину, для List, не гарантирует константы же

я не говорил про константу ? упорядочивание в том смысле что [1,2] не то же самое что [2, 1]

Iterable пусть будет?

кмк это не принципиальный момент

А как будет выглядеть эта композиция? И что должно именно композироваться? По факту, цена только одна, меняется только набор модификаторов к ней

Ну глядите - я никогда не девелопил онлайн магазин и слабо представляю как они МОГУТ комбинироваться в реале (слабо представляю требования), но в общем случае скомбинировать их можно как ЦенаСКупоном(ЦенаСоСкидкой(ЦенаИсходная)).

ну да

Ну глядите - я никогда не девелопил онлайн магазин и слабо представляю как они МОГУТ комбинироваться в реале (слабо представляю требования), но в общем случае скомбинировать их можно как ЦенаСКупоном(ЦенаСоСкидкой(ЦенаИсходная)).

Всё бывает в первый раз:) Однако такая цепочка странно выглядит, как будто за сервис насчитывается три цены.

Ну глядите - я никогда не девелопил онлайн магазин и слабо представляю как они МОГУТ комбинироваться в реале (слабо представляю требования), но в общем случае скомбинировать их можно как ЦенаСКупоном(ЦенаСоСкидкой(ЦенаИсходная)).

Если статичная композиция не устраиваает, можно сделать ее динамичной на уровне выше. Ввести абстракцию Ценообразование с методом цена()

Ну глядите - я никогда не девелопил онлайн магазин и слабо представляю как они МОГУТ комбинироваться в реале (слабо представляю требования), но в общем случае скомбинировать их можно как ЦенаСКупоном(ЦенаСоСкидкой(ЦенаИсходная)).

Дальше, набор скидок не обязательно такой, я выше обозначил ещё и про персональные скидки и акции.

Дальше, набор скидок не обязательно такой, я выше обозначил ещё и про персональные скидки и акции.

Это меняет лишь набор звеньев в этой композиции. Будет там на одну скидку/купон больше или меньше

Это меняет лишь набор звеньев в этой композиции. Будет там на одну скидку/купон больше или меньше

А кто будет определять, какие звенья будут входить в конечную цену при расчёте?

Вот подошёл конец периода, надо посчитать цену чтобы взять деньги

Вот подошёл конец периода, надо посчитать цену чтобы взять деньги

Сорри - пример мона?

Вот я покупатель, пришел купить у вас брюки

И задача стоит - как? Понять какие скидки применить к моим брюкам?

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

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

А. Ну ок. Цена - это деньги с валютой, там такой семантики нет. Если нет - идем на уровень выше. По какому принципу принимается решение принимать купон или нет?