это же не решает проблему

Какая проблема?

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

нет?

Тип один, это твой квадрат

но если у них стороны не равны то это же не квадрат

тогда что это?

И минимум три типажа/интерфейса: квадрат, прямоугольник и ромб

но если у них стороны не равны то это же не квадрат

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

Можно даже явно не декларировать

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

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

Можно даже явно не декларировать

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

Где я это утверждал?

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

Тебе может и не нужен тип прямоугольника

мне может и квадрат не нужен)

Я о том, что все модули работают с интерфейсом

А что там за тип - плевать

у интерфейса тоже тип есть

и имплементация этого интерфейса - это таки тоже подтипы

(если в стремных языках типа java))

у интерфейса тоже тип есть

Нету

ты сейчас конкретно про концепцию типажей

Тип предполагает носитель

Давай например возьмем что-то попроще. Интерфейс FileSystem с поведением для чтения и записи файлов и реализации под разные файловые системы.

тут будет тип "FileSystem" или нет?

Типов таких много будет: кому-то нужны кеши, кому-то нет и так далее. Работать же будешь с тиражом ФС

Собственно, в vfs тоже не конкретный тип лежит, ага

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

оно понятно что там где нужны прямоугольники об этом будет явно задекларировано, а там где и то и то можно - лишьбы углы были под 90% между гранями то просто другой тип нужен, нет?

оно понятно что там где нужны прямоугольники об этом будет явно задекларировано, а там где и то и то можно - лишьбы углы были под 90% между гранями то просто другой тип нужен, нет?

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

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

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

а речь все про треугольники и квадраты)

Ладно, я афк, по улице с телефоном сложно

Народ, а есть какой-нибудь словарь програмерской терминологии (и смежной)? Типо там DRY, SOLID, YAGNI и все в этом духе

Народ, а есть какой-нибудь словарь програмерской терминологии (и смежной)? Типо там DRY, SOLID, YAGNI и все в этом духе

википедия)

ну я имею ввиду сборник

хотя бы со ссылками на вики

надо же знать, что искать)

ну я имею ввиду сборник

Сам забацай )

https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF%D1%8B_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F

Спасибо

https://en.wikipedia.org/wiki/Category:Programming_principles

Респект ??

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

эм

а что там не так

все нормально

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

ты лучше скажи в чем у тебя затык

я не понимают паттерны. Совсем. Я вроде не глупый человек, но понять не могу.

я не понимают паттерны. Совсем. Я вроде не глупый человек, но понять не могу.

"не могу понять" это не вопрос

В Зандстре были паттерны ?

забей на паттерны, понимай принципы

(Паттерны можно спокойно подсмотреть)

https://refactoring.guru/ru/design-patterns/catalog

В Зандстре были паттерны ?

да

да

Видимо, я просто дропнул

В Зандстре были паттерны ?

а как у него книга называется))

а как у него книга называется))

А точно Лол, забыл )

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

:D

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

Тогда рано еще)

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

ты попал в ловушку паттернов

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

поверь, это очень нужная штука

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

ты примеряешь решение проблем не понимая проблем

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

ERROR: S client not available

поверь, это очень нужная штука

#офтоп Я тебя с 8ым мартом через год поздравлю, жди :)

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

события, очереди, работа с датами, что-то такое

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

проблемы же "абстрактно" следующие: - как избавиться от switch/if и упростить логику - как уменьшить вероятность все сломать путем уменьшения количества изменений (добавлять а не менять)

вместо жирного switch можно всякие стратегии юзать. Что бы разделение ответственности соблюдать - декораторы/адаптеры всякие

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

Для меня это штука, для простого понимания готовых проектов :D

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

для уменьшения дублирования - это какие извини?)

Для меня это штука, для простого понимания готовых проектов :D

и что это тебе дает?

и что это тебе дает?

Меньше отвлекаю людей Ну и больше понимаю к чему код который в проекте

ты поймешь по классу Bakery что это фабрика хлебобулочных изделий?

ты поймешь по классу Bakery что это фабрика хлебобулочных изделий?

Да Ты ведь уже сказал что это ?

для уменьшения дублирования - это какие извини?)

на самом деле, почти любые) стратегия например

а сам факт того что это "фабрика" - тебе погоду делает?)

а сам факт того что это "фабрика" - тебе погоду делает?)

Неа

на самом деле, почти любые) стратегия например

нет, они не для этого

нет, они не для этого

и для этого тоже

Неа

вывод - знания паттернов не влияют на "изучение" чужого кода. Оно скорее позволяет тебе коротко и емко описать решение какое-то проблемы. Типа "Петька, жахни логирование в декоратор плиз"

и для этого тоже

обоснуй)

вывод - знания паттернов не влияют на "изучение" чужого кода. Оно скорее позволяет тебе коротко и емко описать решение какое-то проблемы. Типа "Петька, жахни логирование в декоратор плиз"

Давай не будем :(

вывод - знания паттернов не влияют на "изучение" чужого кода. Оно скорее позволяет тебе коротко и емко описать решение какое-то проблемы. Типа "Петька, жахни логирование в декоратор плиз"

крч, что бы находить общий язык с погромистами, называть вещи своими именами)

на самом деле, почти любые) стратегия например

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

крч, что бы находить общий язык с погромистами, называть вещи своими именами)

и для каждой веще куча синонимов

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

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

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

это чаще от безграмотности. Спроси среднестатистического ларавельщика что такое "фасад" и он тебе выдаст глупость

это чаще от безграмотности. Спроси среднестатистического ларавельщика что такое "фасад" и он тебе выдаст глупость

"Плохая штука в Laravel'e. Прочитал на форуме" Что-то типа такого?

это чаще от безграмотности. Спроси среднестатистического ларавельщика что такое "фасад" и он тебе выдаст глупость

грамотность понятие относительное

грамотность понятие относительное

субъективное скорее... а не относительное

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

субъективное скорее... а не относительное

ну да так точнее

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