бывают жесткие

забавно можно раскрутить пример)

ну а чего вдруг school ворнинг делает

не школа, а учитель делает предупреждение

не школа, а учитель делает предупреждение

во-во

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

короч

кто-то после 2 предупреждений и просроченных лаб не ставит зачет

во-во

вот это внутри учителя происходит $this->school->addWarning(new Warning\Ohuel(), $vasya)

в целом класс Student не нужен

есть тупо Person и все

если мы уж делаем систему учета студентов

и хотим потом сделать интеграцию с системой военкомата)

вот это внутри учителя происходит $this->school->addWarning(new Warning\Ohuel(), $vasya)

не, кмк учитель редко ходит в деканат за выговарами ученику

они скорее у себя в листике пометку ставят

а потом на зачете давят

а вот пример с отчислением мне понравился)

не, кмк учитель редко ходит в деканат за выговарами ученику

ок, замени $school на $classLog

там скорее $this->listOfPizdabols[] = $student

))))

там скорее $this->listOfPizdabols[] = $student

это должен быть Collection

иначе у тебя будут дважды и трижды пиздаболы

согласен

а, ты имеешь ввиду Set

хм

но если я только после 3 предупреждений иду в деканат?

$loafers->add($vasia)

тогда мне надо $this->addWarningFor($vasya);

это твоя new Strategy\GoodTeacher() или BadTeacher()

KindTeacher(), AngryTeacher()

нет

if ($this->numberOfWarningFor($vasya) > 3) { $this->school->ebanut($vasya); }

это ты замутил композицию

а тут надо

а хотя тоже не надо

это внутри учителя происходить должно

$this->mood = new Angry();

это внутри учителя происходить должно

ну, у учителя есть интерфейс

инкапсуляция ж

это и есть стратегия

а чисто полиморфизмом будет его поведение

стратегия - это паттерн

поведение определяет

не надо называть все стратегиями

это поведенческий паттерн

в данном случае это "настроение"

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

да да

да, но настроение это и есть паттерн стратегия

в данном случае это "настроение"

или характер

названия паттернов - для программиста. Названия сущности - для бизнеса

да, но настроение это и есть паттерн стратегия

ты это знаешь, другой программист может знает и этого достаточно

да, но настроение это и есть паттерн стратегия

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

ты это знаешь, другой программист может знает и этого достаточно

тогда я сделаю $company->fire($programmist)

$this->mood = new Mood\Happy();

тогда я сделаю $company->fire($programmist)

исключение словишь "Only CTO can fire programmers"

$this->character = new Charater\SvolochPoslednya

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

настроение это в чистом виде паттерн стратегия

ну так и что?

настроение это в чистом виде паттерн стратегия

но настроением это не перестало быть)

потому что оно определяет поведение

окей

так и хорошо)

натсроение - это подтип стратегии. То есть более конкретное название для типа сущности

да ради бога

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

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

например называть вещи Catalog вместо ProductRepository

например называть вещи Catalog вместо ProductRepository

Catalog implements Repository

Catalog implements Repository

эм.... нет

Catalog это интерфейс

скорее всего

да

ProductREpository implements Catalog - так норм

блин

ну ок

не важно

важно)

это пожалуй самое важное

ProducteRepository extends AbstractRepository implements Catalog

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

и тут адаптер, в котором можно наследовать!)

это называется "самодокументируемый код"

и тут адаптер, в котором можно наследовать!)

а зачем тебе AbstractREpository? в нем нет публичных методов же

а "общие штуки" ты можешь как зависимости передать

ну это доктриновский например

ради бога

не наследуйся от доктриновского репоса

он не для этого сделан

он может быть вполне себе абстрактным

и тогда ну просто вынужден

хоть сальто делай, а передать его не могу, только наследника)

ну просто профита от того, что я явно привяжусь к классу в конструкторе или в иерархии особо нет

ибо к интерфейсу привязаться все равно не могу

и мокать все равно придется со всем говном, что оно там несет в себе

final class Catalog { private $repository; public function __construct(EntityRepository $repository) { $this->repository = $repository; } public function add(Product $product) { } }

и пусть в EntityRepository будут дефолтные методы аля find или add или remove

а конкретика в Catalog

и опять же никакого наследования

и кода столько же