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

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

я кстати согласен с сообщением выше, зачем тут валюта?

Ну я черновой вариант привел - МБ и не нужна

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

Беру брюки напрокат? Мы точно об онлайн магазине говорим? о_О

Ну да не суть

Беру брюки напрокат? Мы точно об онлайн магазине говорим? о_О

идея для стартапа — брюки as a service

Беру брюки напрокат? Мы точно об онлайн магазине говорим? о_О

Изначально речь шла о сервисе по подписке.

Изначально речь шла о сервисе по подписке.

А. Ок. Щас сформулирую

идея для стартапа — брюки as a service

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

кто со мной пилить?

С носками кто-то такое уже сделал

надеюсь они потом их не забирали

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

я бы записался, носи я брюки впрочем, именно из-за глажки и не ношу

уже первый клиент

тут только один минус — не ясно, куда блокчейн всунуть, а какой сейчас стартап без этого?

почему не ясно? очевидно в блокчейне история каждой пары брюк

кто носил и тд

пора искать девопса, трёх хаскелистов (то есть половину от всего имеющихся на рынке) и двух евангелистов

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

Такой вопрос. А какие факторы могут приниматься во внимание при расчете цены за последующие периоды?

почему не ясно? очевидно в блокчейне история каждой пары брюк

нафига?

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

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

хотя что я спрашиваю, это ж блокчейн

ну как нафига, чтобы проверить что брюки ношены определенное количество раз, не превышающее договор, и тд, их историю

нафига?

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

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

точняк, машинное обучение

тогда ещё и датасаентист нужен в команду

все, надо ещё VR вснуть (для примерки брюк), и можно на ICO

пацаны, у вас работы нет чтоли?

одни и те же лица)

Мужчина, вы не видите, у меня обед?

Такой вопрос. А какие факторы могут приниматься во внимание при расчете цены за последующие периоды?

Можно попробовать сделать это так: интерфейс Купон. У него метод Цена новаяЦена(Цена). Имплементации купона прямо или через композицию учитывают историю юзера, которую берут из базы/другого сервиса. Но это неточно.

черт заорал на весь бц

Такой вопрос. А какие факторы могут приниматься во внимание при расчете цены за последующие периоды?

Наличие/отсутствие скидки (т.к. они имеют срок действия) - в простейшем случае. Срок действия скидки независим от продолжительности биллинг периода.

как хитро чел заставил всех на себя поработать)

дайте говорит мне реализацию)

так зарождался амазон ну или хотя бы озон ?

дайте говорит мне реализацию)

Лесенкой

Наличие/отсутствие скидки (т.к. они имеют срок действия) - в простейшем случае. Срок действия скидки независим от продолжительности биллинг периода.

Ну если срок действия скидки то ничто не мешает запилить контракт Скидка с методом старая цена -> нова цена и запилить СтатичнаяСкидка(процент), СкидкаСПериодом(Скидка, Период)

так зарождался амазон ну или хотя бы озон ?

кобзон

кобзон

три ГЕТ_ПЕСНЯ по флаеру по цене двух

Ну если срок действия скидки то ничто не мешает запилить контракт Скидка с методом старая цена -> нова цена и запилить СтатичнаяСкидка(процент), СкидкаСПериодом(Скидка, Период)

И самое главное - я еще не конкретизировал что выше есть Процент и Период

И самое главное - я еще не конкретизировал что выше есть Процент и Период

Процент от цены, период - какой-то заранее известный период, месяц, три месяца, год и т.п.

Процент от цены, период - какой-то заранее известный период, месяц, три месяца, год и т.п.

В примере выше это ничего не меняет

В примере выше это ничего не меняет

Как в итоге будет выглядеть вызов расчёта?

Или как вообще будет применяться этот набор классов

ИМХО рановато об этом говорить, но пока что как Цена.цена()

Или вы - о матрешке?

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

Может ввести интерфейс который возращает модификаор цены (кофициент), также имеется поле или метод который определит интерфей типа КомбинацияКоф, коьорый уже буде возращать итоговый кофициент, при это Коф и КомбинацияКоф может быть одним обектом

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

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

Ну этоточень абстрактно и требует доработки

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

Но с этим можно легко справиться. Я обычно справляюсь примерно так: https://github.com/project-avral/oo-atom/blob/master/atom-basis/src/main/java/oo/atom/codegen/bytebuddy/smt/SmtAtomEquals.java

Но с этим можно легко справиться. Я обычно справляюсь примерно так: https://github.com/project-avral/oo-atom/blob/master/atom-basis/src/main/java/oo/atom/codegen/bytebuddy/smt/SmtAtomEquals.java

То есть - все методы класса final, сам класс не final. Наследовать можно но нельзя добавлять новых полей, методов, имплементировать новые интерфейсы. Только новые конструкторы

То есть - все методы класса final, сам класс не final. Наследовать можно но нельзя добавлять новых полей, методов, имплементировать новые интерфейсы. Только новые конструкторы

Ужас какой

Ужас какой

Субъективно

То есть - все методы класса final, сам класс не final. Наследовать можно но нельзя добавлять новых полей, методов, имплементировать новые интерфейсы. Только новые конструкторы

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

То есть - все методы класса final, сам класс не final. Наследовать можно но нельзя добавлять новых полей, методов, имплементировать новые интерфейсы. Только новые конструкторы

Поясню. Оверрайдить методы равноценно content couplingу. Худшее что можно придумать в наследовании. Добавление новых полей и методов - размазывание cohesionа по стенке и нарушение SRP

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

Под аггрегацией что имеетя ввиду? Fluent API или сеттеры какие?

Внутри твоего объекта хранить инстанс объекта, вместо его наследования.

Внутри твоего объекта хранить инстанс объекта, вместо его наследования.

А. Не - вначале все верно было. Для полиморфизма

Тут вот какой фокус

Семантически такой наследник абсолютно идентичен родителю (если не применять instanceof и рефлексию), только записывается в матрешке компактнее

Семантически такой наследник абсолютно идентичен родителю (если не применять instanceof и рефлексию), только записывается в матрешке компактнее

Он - как бы подмножество возможных истансов родителя

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

ERROR: S client not available

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

Есть же чудесные jvm-языки типа Clojure, в которых можно хоть нотами код записывать

Интересная, кстати, идея. Музыкальное программирование

Играешь мелодию - пишешь код. Фальшиво сыграл - тесты красные

Потому что ООП в том виде, в котором оно в жаве, немного сломано

Играешь мелодию - пишешь код. Фальшиво сыграл - тесты красные

Чуть не сделал своим дипломом.

С автокоррекцией. Кстати, хотел объектно-ориентированно. Понял, что хуйня, а переделывать лень было, надо было диплом на какую-то тему писать срочно.

Ну одна из причин

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

То же самое можно сказать и про спринги.

А вообще концепции устаревают, а все всё равно хотят на своём языке

Потому что ООП в том виде, в котором оно в жаве, немного сломано

Сломано ООП не в джаве, а у людей в голове такое представление было, исходя из которого они язык и спроектировали

А т.к. жава простая и мощная — тянут в нё

Поэтому получаются попытки исправить дерево, которые уже выросло

Где лучше?

То же самое можно сказать и про спринги.

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

Сломано ООП не в джаве, а у людей в голове такое представление было, исходя из которого они язык и спроектировали

Это-то понятно, что в голове От этого оно не становится работающим в джаве

Огонь

Где лучше?

Делегация > наследование

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

Согласен.

Делегация > наследование

Больше не значит лучше. Больше инвариантов - тяжелее поддерживаемость

Оно не нарушает инкапсуляцию

Суть в этом

Завезли бы в жабку утиную типизпцию...

Зочем

Там и так всё не очень круто с типами

Завезли бы в жабку утиную типизпцию...

Опять натягивание.

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

ИМХО "натягивание" - благо. Если проследить историю парадигм от процедурного П продолжая стркутурным и заканчивая ООП/ФП - каждая новая парадигма натягивает свои правила по имя maintainability

ИМХО "натягивание" - благо. Если проследить историю парадигм от процедурного П продолжая стркутурным и заканчивая ООП/ФП - каждая новая парадигма натягивает свои правила по имя maintainability

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

Структурная положила табу на goto. ООП избавил от адресной арифметики, ФП - от мутабилити

Это C++

goto живет