а я вот не понял разницу между бриджем и стратегией =\

Бридж помогает впихнуть невпихуемое)

https://en.wikipedia.org/wiki/Coupling_(computer_programming)

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

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

а я вот не понял разницу между бриджем и стратегией =\

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

а ещё в русском переводе ужасные названия шаблонов в книге - до сих пор не запомнил, кто там "посредник", прокси или медиатор. Но на самом деле это всё (в смысле шаблоны) наверное не так важно. Вот наследование vs композиция - важно по-моему и вот тут непонятно, что такое семантика наследования и как её найти =\

Офигеть, тут дисскуссия. А начинали за то, что трейты говно.)))

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

хз, почему нельзя в рантайме поменять? Что мешает?

хз, почему нельзя в рантайме поменять? Что мешает?

Если сделаешь метод, то получится стратегия

Сам принцип шаблона

Мешает

Реализатор передается в абстракцию и все. Дальше его не изменить. А в стратегии можно

Так как стратегия не выстраивает стрктуру а меняет поведение

Как композитный шаблон

Сам принцип шаблона

а зачем тогда разные имплементации? В смысле если их нельзя менять - зачем их больше одной и вообще выделять отдельно?

а зачем тогда разные имплементации? В смысле если их нельзя менять - зачем их больше одной и вообще выделять отдельно?

Их можно 1 раз выбрать на основе конфига или условия и передать в абстракцию и все

А в стратегии реализатор можно в рантайме поменяиь

не нужно просто воспринимать mvp как отдельный проект. MVP это лишь начальная фаза продукта. Фразы типа "забей. нахерач по быстрому на ларе потом нормально перепишем" это групость полнейшая. Вопервх потому что если это взлетит никто переписывать ничего не будет - если хайп трейн с инвестициями тронулся то тебе надо быстрее его гнать а не замедлять

@fes0r Можешь плиз дать совет, как можно грамотно это объяснить людям, которые отвергают мысль, что MVP это начальная фаза проекта, но не "прототип". Потому что я честно говоря, сильно заебался, это объяснять. Ну или наверное потому что, я этого не умею делать.

Через сеттер например

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

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

Замена наследованию?

Как вариант

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

типа множетсвенное наследование для тех у кого пхп

?

@fes0r Можешь плиз дать совет, как можно грамотно это объяснить людям, которые отвергают мысль, что MVP это начальная фаза проекта, но не "прототип". Потому что я честно говоря, сильно заебался, это объяснять. Ну или наверное потому что, я этого не умею делать.

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

типа множетсвенное наследование для тех у кого пхп

Чего?

но как то не праивльно налсдеование тут не подохлдит

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

это можно вывести из названия - minimum viable product - минимально жизнеспособный продукт

Через сеттер например

то есть всё-таки реализации отличаются наличием возможности изменения имплементации (сеттер)? о_О

прототипы - это всякие мокапы и тд

но как то не праивльно налсдеование тут не подохлдит

Декоратор должен имплементировать интерфейс декорируемого объекта, в чем проблема?

то есть всё-таки реализации отличаются наличием возможности изменения имплементации (сеттер)? о_О

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

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

наверное над этим стоит в первую очередь задуматься =\

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

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

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

Именно

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

Ок, но MVP можно начать делать правильно изначально. Потому что иначе, переписывание и это уже другой проект по сути. Потому что ты его переписываешь с нуля. И вот никогда не бывает такого, чтобы когда это взлетит, тебе дали время чтобы ты переписал "нормально", потому что это полная хуйня. Нужно сразу писать нормально и закладывать время на нормальный вариант архитектуры.

я и не говорю, что надо делать его неправильно

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

В стратегии мы меняем поведение объекта изнутри когда звхотим, а в бридже мы просто выстраиваем структуру классов на основе какого-то кондишина и дальше этим пользуемся

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

я и не говорю, что надо делать его неправильно

Ок. Это не особо важно. Важно то, как донести эту блядскую, но в то же время истинно правильную мысль, что: MVP это не ебанное проложение-прототип, а фундамент, на котором будет держаться весь проект. Гибкий и расширяемый Core, который местами говно, но который не на один раз.

В стратегии мы меняем поведение объекта изнутри когда звхотим, а в бридже мы просто выстраиваем структуру классов на основе какого-то кондишина и дальше этим пользуемся

ну, "когда захотим" - это уже наверное перебор, всё-таки в рамках операции наверное не стоит менять поведение, как-то уже опасновато выглядит

Ок. Это не особо важно. Важно то, как донести эту блядскую, но в то же время истинно правильную мысль, что: MVP это не ебанное проложение-прототип, а фундамент, на котором будет держаться весь проект. Гибкий и расширяемый Core, который местами говно, но который не на один раз.

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

ну, "когда захотим" - это уже наверное перебор, всё-таки в рамках операции наверное не стоит менять поведение, как-то уже опасновато выглядит

Все зависит от задачи. Напрмер если в объекте есть данные и нам надо отправить их в 3 разных места, мы по очереди меняем реализаторы и вызываем send()

Все зависит от задачи. Напрмер если в объекте есть данные и нам надо отправить их в 3 разных места, мы по очереди меняем реализаторы и вызываем send()

И нам не надо создавать новые абстракции и передавать туда реализаторы с данными как в случае с бриджем

Все зависит от задачи. Напрмер если в объекте есть данные и нам надо отправить их в 3 разных места, мы по очереди меняем реализаторы и вызываем send()

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

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

Дак и не надо. Смена поведений обычно через сеттеры делается

И сама абстракция ничего не знает про реализаторы

За исключением интерфейса

Дак и не надо. Смена поведений обычно через сеттеры делается

спасибо, до меня даже вроде что-то дошло =)

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

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

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

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

просто если им этих примеров мало - тут уже не уверен, что что-либо спасет

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

Прежде, было все норм, но теперь руководство вбили себе в голову, что если пригласить +10 человек, то проекты магическим образом будут делаться быстрее. Мне кажется, что всё это бесполезно.

ну в этой ситуации уж точно

Всем привет. Пытаюсь тут осознать отказ от геттеров и сеттеров. С сеттерами в голове проблем не возникло. А вот с геттерами задался вопросом. Как мне тогда из энтити полчить данные? В голову пришел какой-то такой метод: class Post { private $name; public function toView() { $view = new PostView(); $view->name = $this->name; return $view; } } class PostView { public $name; } Скажите, пожалуйста, хорошая ли это идея?

скорее, наоборот - вьюшка должна завязываться на сущность

а не сущность на вьюшку

Всем привет. Пытаюсь тут осознать отказ от геттеров и сеттеров. С сеттерами в голове проблем не возникло. А вот с геттерами задался вопросом. Как мне тогда из энтити полчить данные? В голову пришел какой-то такой метод: class Post { private $name; public function toView() { $view = new PostView(); $view->name = $this->name; return $view; } } class PostView { public $name; } Скажите, пожалуйста, хорошая ли это идея?

мне кажется лучше обернуть Post в PostView. Правда не очень понятно что ты хочешь сделать

А просто прочитать значение свойства никак нельзя?)

А просто прочитать значение свойства никак нельзя?)

Оно прайват

скорее, наоборот - вьюшка должна завязываться на сущность

А как это должно быть реализовано?

А с сеттерами как разрулил?)

class PostView { public $name; public static function create(Post $post): self {...} }

А с сеттерами как разрулил?)

Сделал их семантично логичными. Типо ренейм.

дальше имхо понятно

class PostView { public $name; public static function create(Post $post): self {...} }

Но ведь в этой функции нет доступа к прайват полям?

Но ведь в этой функции нет доступа к прайват полям?

да, сорри, тупанул

@igor_kamyshev вообще хз, на таком простом примере получается, что нет смысла вот это вот всё проделывать, т.к. никакой логики в объекте Post нет. Так-то можно наверное и не делать никакого PostView =\ (осторожно, кнопкодавы могут научить тебя плохому!)

@igor_kamyshev вообще хз, на таком простом примере получается, что нет смысла вот это вот всё проделывать, т.к. никакой логики в объекте Post нет. Так-то можно наверное и не делать никакого PostView =\ (осторожно, кнопкодавы могут научить тебя плохому!)

Ну ты представь, что там есть куча логики.

В обязанности логики сущности должно входить приведение самой сущности к вьюхе?

Ну ты представь, что там есть куча логики.

ну я бы так нопесал наверное: class PostView { private $post; public function __construct(Post $post) { $this->post = $post; } public function toView() {//...} }

В обязанности логики сущности должно входить приведение самой сущности к вьюхе?

Вот и меня это смущает немного. Но не могу найти другого решения.

ну я бы так нопесал наверное: class PostView { private $post; public function __construct(Post $post) { $this->post = $post; } public function toView() {//...} }

Ну а как доступиться до полей то? Они прайват должны быть.

кто пробовал держать задачи кролика по несколько часов? Держать - в смысле не давать ask

Ну а как доступиться до полей то? Они прайват должны быть.

в случае если в Post добуя логики - у тебя нет там геттеров, у тебя есть методы в которых шото происходит. Но в реальности наверное геттеры какие-то всё равно будут

в случае если в Post добуя логики - у тебя нет там геттеров, у тебя есть методы в которых шото происходит. Но в реальности наверное геттеры какие-то всё равно будут

Но не хочется же. @fes0r вон все время рассказывает, что нужно иначе строить сущности.

Но не хочется же. @fes0r вон все время рассказывает, что нужно иначе строить сущности.

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

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

Я понимаю. Но я и сам чувствую опасность геттеров. Они доступ до внутреннего состояниях сущности. А я не хочу такой доступ. Я хочу только ДТО какое-нибудь с частью данных.

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

Реальный пример - какая-то ентити с набором данных, которую нужно закэшить. Можно решить путем создания декоратора-кэшера. Который поверх результата от деятельности декорируемой сущности будет сохранять в кэш результат или выбирать из кэша.

Я понимаю. Но я и сам чувствую опасность геттеров. Они доступ до внутреннего состояниях сущности. А я не хочу такой доступ. Я хочу только ДТО какое-нибудь с частью данных.

Бахни маппер через рефлексию ?

Есть реализации гидраторов/экстракторов, основанные на этом

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

Тут основной вопрос в том есть у тебя выбор (не юзать сущности для ui) или нет

Тут основной вопрос в том есть у тебя выбор (не юзать сущности для ui) или нет

это типа если вариант с CQRS, то можно обойтись и без геттеров?

Ох, минут через 15 доберусь до ноута оформлю мысль

Бахни маппер через рефлексию ?

Но зачем?..

Тут основной вопрос в том есть у тебя выбор (не юзать сущности для ui) или нет

Я хочу на основе сущностей ответ для API формировать. В таком случае, в правильном направлении думаю?

Но зачем?..

1) проблема доступа к private-полям будет решена 2) вынесешь логику создания DTO в отдельный класс, где ей и место

1) проблема доступа к private-полям будет решена 2) вынесешь логику создания DTO в отдельный класс, где ей и место

Но тогда будет маппер, который все знает о сущности. Разве это не грязь?

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

например, на хаках с рефлексией DI-контейнеры построены и им живется неплохо

1) проблема доступа к private-полям будет решена 2) вынесешь логику создания DTO в отдельный класс, где ей и место

если у него там логика и ему надо отобразить результаты работы логики - это не сработает. Получишь доступ к внутренним данным, а нужны результаты =\

ну гидраторы/экстракторы тоже иногда даже используются

https://github.com/Ocramius/GeneratedHydrator например такой

не скажу, что это right way, но имеет право на существование

Ох, минут через 15 доберусь до ноута оформлю мысль

не добрался)