ссылка выше адресом

ты о том что я тебе сказал убрать кучу ифов и заменить на метод supports явно разделив кто решает какая стратегия должна выполняться?

угу

у меня не стыковка в башке

тогда получается эти ифы лезут в сами стратегии

и у меня чет это не вяжется в голове это

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

в твоем случае за выбор стратегии отвечал сам этот "навигатор"

а в примере по ссылке стратегия назначалась на уровень выше

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

нифига не понял, но спасибо ))

т.е. по сути навигатор - это мой яблочный спас

нифига не понял, но спасибо ))

почитай еще про chain of responsibilities. Это по сути гибрид

т.е. по сути навигатор - это мой яблочный спас

да, он самый

и туды суппортс

и туды суппортс

суппортс в стратегию конкретную

а

и туда же условия

и иначе фолс отдавать

ну то есть логика такая: для всех стратегий: если стратегия это могет вызвать стратегию

а в спасе форычем обходить уже

которая тру

ту и берем

но я не разбирался нафига тебе там стратегии)

ну типа яблоки там отдаются только четные или только нечетные

и есть 3 варианта

есть мнение что можно было бы сделать элегантнее но мне было лень читать требования

у юзера нет яблок - отдать любое

у юзера есть четное яблоко - отдать следующее четное

у юзера нечетное яблоко - отдать следующее нечетное

мне все еще лень читать)

как элегантнее - я хз, пока не придумал

ёпт, 3 строчки лень читать ? Вот это уровень ))

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

оставить как есть и не убивать N часов на мифическую проблему))

это проблема на 150килорублей

думаю можно и убить n часов

врядли 150килорублей стоят именно эти 3 ифа)

в принципе это все задание

там еще пара мелких условий

но они не принципиальны

> таким образом юзеры делятся на 3 типа: 1 тип - яблок нет - берем любое. 2 тип яблоки четные - берем только четные, если есть. 3 тип берем ток нечетные, если есть кто знает какие у юзера яблоки? четные или нечетные? Как ты определяешь это?

бд знает

бд ничего не знает, она все хранит

у яблока айдишник юзера есть

который взял

крч яблоко знает

то есть яблоко знает кто его взял и какое оно - четное или нечетное

угу

зачем яблоку знать кто его взял?

пользователь знает какие яблоки он взял. И соответсвенно если у него есть оные то они либо все четные либо все нечетные, так?

ну

а, ну да

я по юзеру и смотрю

туплю прост

user.takeApple(apples) и внутри что-то типа apples.likeThis(this.apples.last())

ну это условие

а лайк типа говорит, какое яблоко отдать ?

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

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

нуу хз, хз

а мой вариант тебе чем не нравится ?

я не вижу тут стратегий

задачу тебе дали какую - стратегии туда запихнуть или просто задачу?

if($this->user->apples->count() && $this->user->apples->first()->id % 2 == 0){ return Apple::Even()->get(); }

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

не, просто задачу. Я прикинул - вроде сойдет

я прочитал

ERROR: S client not available

> $this->user->apples->count() прощей инкапсуляция, сокрытие информации, здравствуй высокая связанность

там про слабую связанность

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

а ты ща говоришь на непонятном для меня языке ))

1. кто выдает яблоки? 2. что этот кто-то должен знать о том где пользователь яблоки хранит? может быть он не хочет этого знать

корзина выдает яблоки

корзине похер как юзер яблоки хранит

главное, чтобы он нужное получил

> user->apples->count() ну вот не похер же)

оно знает как оно их хранит

ну дык это юзер

> $this->user->apples->count() судя по $this->user это не юзер

это кто-то другой знает как хранятся яблоки

это спаситель яблок )

он знает )

ну вот а не должен

> $this->user->apples->count() судя по $this->user это не юзер

А для чего предназначен метод который это юзает?

есть два варианта: - корзина получает ID юзера который просит яблоко и закрепляет за ним что этот юзер в предь будет получать только четные/нечетные - корзина будет получать сэмпловое яблоко - типа "дай еще таких". И уже будет разруливать че как брать. Так мы уменьшим связанность

А для чего предназначен метод который это юзает?

спасать яблоки (выдавать вернее)

но это не точно

он нужен для того, чтобы яблоки юзеру сохранять

Ааа, сохранять

я думаю так. Что юзер должен знать, какие яблоки брать

яблоко должно просто иметь айдишник

а корзине похуй че отдавать

если уж в реале

пусть юзер копошится и нужное яблоко ищет

тогда юзер имеет метод тейк эпл

берет яблоко

смотрит его и решает, захавать его совсем или нет

и тогда все логично. Юзер знает, как он хранит яблоки и какое ему нужно

остальным насрать: что яблокам, что корзине