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

это не отменяет факта того, что "споры" от безграмотности. Вместо того что бы спорить стоит разобраться в истории

и общая терминология

статегии выполняют простую роль. Позволяют тебе масштабировать логику с соблюдением O/C принципа. То есть вместо жирного ифа который надо править на каждый чих можно добавлять еще одну стратегию как отдельный класс.

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

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

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

это не отменяет факта того, что "споры" от безграмотности. Вместо того что бы спорить стоит разобраться в истории

как в приколе как вам удалось дожить до 100лет, я просто нискем не спорил, но это не возможно, ну не возможно так не возможно

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

использовать

как в приколе как вам удалось дожить до 100лет, я просто нискем не спорил, но это не возможно, ну не возможно так не возможно

гы

как в приколе как вам удалось дожить до 100лет, я просто нискем не спорил, но это не возможно, ну не возможно так не возможно

?

использовать

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

а статегии нужны что бы в этом большом и жирном классе убрать switch

это цель

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

все зависит от реализации

короч

стратегия же позволяет вынести функционал в эту самую зависимость, я про это и говорю)

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

убрать дублирование кода можно намного проще

речь то про то, что стратегии тоже на это могут навести

ой

паттерны

убрать дублирование кода можно намного проще

трейтами?

трейты эт такое себе

не серебряная пуля)

речь то про то, что стратегии тоже на это могут навести

смотреть на стратегии нужно с позиции разделения ответственности

а не "дублирования кода"

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

Я ничего не говорю, конечно они роль другую выполняют

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

и вот такое дублирование лучше не трогать

но ведь при этом они вполне могут и дублирование уменьшить

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

Создаем трейт, пихаем метод и делаем $status = false/true, и нема дублирования (не серьезно конечно же)

но ведь при этом они вполне могут и дублирование уменьшить

я повторюсь. исключи это из идей паттернов. Они не для этого

странно

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

Создаем трейт, пихаем метод и делаем $status = false/true, и нема дублирования (не серьезно конечно же)

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

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

Ну я ж дописал (((((((

странно

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

а много времени нужно, чтобы осмыслить вот это все?

Вопрос про понимание паттернов в книге актуален скорее всего

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

а декомпозиция - не паттерн?

а много времени нужно, чтобы осмыслить вот это все?

если ты понял ООП, то не особо

главное - найти пример, который для тебя понятен

а много времени нужно, чтобы осмыслить вот это все?

там @mkusher скидывал песенку про чувака у которого 20 лет опыта но это 1 год повторенный 20 раз. Так что все сильно относительно.

их полно и все разные

если ты понял ООП, то не особо

а ты понял ООП?)

хз как это определить

главное - найти пример, который для тебя понятен

Ему нужно понять зачем вообще эти паттерны Понимание конкретного паттерна не слишком сложно

не, ну я имею ввиду, наследование там, сущности, классы, объекты

интерфейсы

для чего это все

представь что я фанат процедурщины и попробуй мне объяснить

не, ну я имею ввиду, наследование там, сущности, классы, объекты

это не ооп

представь что я фанат процедурщины и попробуй мне объяснить

ну уж нет

представь что я фанат процедурщины и попробуй мне объяснить

Сядь на Jav'y и попиши на своей процедурщине !

Сергей, отстань, я знаю, что ты монстрюга в программировании :D Я даж не поблизости

для чего это все

я год назад уже разделил графу "ооп" при оценке сотрудников на "процедурщина с классами" и "ооп".

Сядь на Jav'y и попиши на своей процедурщине !

звучит опасно

я год назад уже разделил графу "ооп" при оценке сотрудников на "процедурщина с классами" и "ооп".

+++

Сядь на Jav'y и попиши на своей процедурщине !

запросто. Так большинство и делает собственно

я год назад уже разделил графу "ооп" при оценке сотрудников на "процедурщина с классами" и "ооп".

Как отличаются?

создаешь класс который хранит данные, и другой класс с процедурами

запросто. Так большинство и делает собственно

По факту - там только ооп

создаешь класс который хранит данные, и другой класс с процедурами

ну ты разделил состояние и действияя

По факту - там только ооп

чем ООП отличается от процедурного программирования?

нарушил инкапсулирование

ну если у тебя класс - контейнер для твоего продцедурного кода :D

чем ООП отличается от процедурного программирования?

Ничем )

иногда это прикольно но не оопшно))

ERROR: S client not available

Ничем )

любое ОО = процедурщина но не всякая процедурщина = ОО

тот же ddd

тот же ddd

оно тут причем?

есть сервисы, есть домены которые над entity :D

есть сервисы, есть домены которые над entity :D

предлагаю перечитать Эванса)

состояние в домене

так чем ооп от процедурщины отличается?

когда у тебя entity это анемичные модели данных - у тебя врядли выйдет хорошо выразить в коде бизнес логику

предлагаю перечитать Эванса)

это очень грубый пример)

ну то есть в теории конечно можно, но будет больно

о онемичные модели или не онемичные срач

да любое решение несет в себе боль

Сядь на Jav'y и попиши на своей процедурщине !

Jav'y - это что-то на исландском?

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

в целом "сервисы, сущности" и т.д. это лишь названия. Это как паттерны. Суть же DDD немного в другом.

Jav'y - это что-то на исландском?

Практически в точку

в целом "сервисы, сущности" и т.д. это лишь названия. Это как паттерны. Суть же DDD немного в другом.

общение с domain expert на одном языке (имхо)

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

по домену и сервисам

и вытекает от туда та процедурщина о который ты говорил 1 объект для данных другой для действий

ну так может быть но не обязательно

так чем ооп от процедурщины отличается?

тем где находятся данные и где находится код который с этими данными работает.

там очень тонкая грань

god object это ооп ?)

данные в нем

код работающий с ними тоже

OOP

объект не может быть богом если он один)

объект не может быть богом если он один)

С большой буквы, ну :(

ооп это отражение реального мира через объекты?

ооп это отражение реального мира через объекты?

нет

а что отражает ооп тогда?)