А вот и новый видос подъехал. Пишите свои вопросы в комментариях, будем отвечать на них на следующем стриме. Плейлист с паттернами: bit.ly/2tyvweF Наша группа в вк: extreme...
ОМГ! Как теперь распомнить КИСОКЛАСС))) Подача материала - топчик! Спасибо за столь крутое видео. Полагаю, вы многим помогли с пониманием и дальнейшим использованием этих знаний!
На мой взгляд лучше второй вариант: При первом - все публичные методы и переменные объекта класса родителя будут доступны. При втором подходе (это ж композиция называется) ничего не светится да и жить легче.
ахахах огонь конечно)))) с юморком)) инфа конечно не разжевана и приходится пересматривать по сто раз... но зато доходит так или иначе и смотреть в кайф такие видосы
Так с половиной паттернов у людей и происходит. Когда Тебе решение вдруг не кажется костыльным наконец - выясняется что есть такой паттерн. Паттерны это опыт и боль тех, кто прошел путь ранее
Второй вариант ИМХО часто лучше, так как поможет избежать возможной проблемы в будущем, когда потребуется отнаследовать, а уже уппс(множественное наследование классов есть только в паре языков). Тут очень важным критерием выбора является возможность использования других методов кисокласса. В этом случае первый лучше.
множественное наследование тоже пораждает кучу ромбовидных связей, несостыковки, одинаковые названия и т.п., лучше не юзать эту фичу. второй вариант мне показался юзабельнее грубо говоря адаптер - прокладка между интерфейсом и реализуемым классом
Как то сложно. Вот простое объяснение: "Адаптер - это структурный паттерн проектирования, который позволяет объектам с несовместимыми интерфейсами работать вместе."
Сегодня впервые наткнулся на твой канал. Можно сказать что я не "Маленький и тупой", я только родился, к тому же без мозгов)))) Так вот, посмотрел видео про интерфейсы. Вроде понял. Посмотрел видео интерфейсы на практике, там столько всего, что я только запутался, голова чуть ли не взорвалась и я уже стал сомневаться, что понимаю, что такое интерфейс. Но тут после просмотра, этого видео, осознал, что все понял. Странная хрень твориться......
Мужик, я от раздумий как реализовать одну механику в игре, свои мозги в желе превратил, а оказываеться её можно настолько изично с помощью этой штуки сделать
Материал огонь, я хоть изучаю РНР но все же сморю видос и делаю на РНР и результаты вдвойне радуют... Продолжение нужно однозначно!!! Кому интересен пример на РНР вот он: interface IRequester { public function send(string $message): void; } class Requester { public function sendRequest(string $message): void { echo "Отправляем сообщение: $message "; } } $objectRequester = new Requester(); $objectRequester->sendRequest('Привет мир!!!'); // Реализация через Класс class Adapter1 extends Requester implements IRequester { public function send(string $message): void { $this->sendRequest($message); } } $objectAdapter1 = new Adapter1(); $objectAdapter1->send('Паттерн Адаптер (Adapter1)');
То есть, вместо того, чтобы менять шестерёнки в музыкальной шкатулке на шестерёнки с ручками (которые там не предусмотрены), мы просто приделываем к старым шестерёнкам ручки
Спасибо, все очень доступно. Получается, что во втором варианте еще и sealed класс можно так модифицировать, а первый вариант такой возможности не даст.
Ну ок, реализую я этот адаптер. А потом в коде я буду использовать получается только конректно кисо-класс там, где нужно исопльзовать возможности того интерфейса, а родительский класс и тот код, где он применялся не нужно будет трогать?
реально нужно просто запомнить как это делается. через пару лет работы ты уже не думаешь "Так , вот тут я буду применять адаптер ". Ты просто по умолчанию так пишешь. Это как пдд и вождение: если спросить у водителя с опытом лет 10 какое то правило , то он навряд ли процитирует его буква в букву , но все равно будет соблюдать , т.к просто привык
А почему в данном примере нельзя сделать наследование нашего класса Requster с методом SendRequest() нельзя унаследовать от нужного нам интерфейса ISender с методом Send() и просто реализовать этот метод Send() внутри класса Requster, чтоюы в этом методе также вызывался метод SendRequest() ?
Представь, что Requester - старый, давно устоявшийся в системе класс, который никак менять нельзя, иначе всё сломается. Adapter нужен, чтобы обернуть этот класс для получения нового функционала, который доступен в интерфейсе ISender. Например, представь давно существующий класс List. Ты не можешь и не должен менять его и добавлять туда что-то, но ты можешь создать Adapter для работы с этим классом, например для добавления 3-х элементов в одной операции в каком-нибудь методе add3Elements(el1, el2, el3). Надеюсь понятно объяснил
Эээ, типа надо просто зафигачить класс и отнаследоваться?!))))) в питоне, это конечно жоподробильня, которая только усложняет код(я про интерфейсы), тем не менее - очень интересно👌
неа. Декоратор (а это паттерн, не только фича в Python) изменяет поведение безотносительно добавления интерфейса в недоступный для изменения класс. Т.е., там мы подсовываем (декорируем) исходный класс/методы некоей функциональностью, но новый интерфейс можем и не добавлять
чёт я не понял 🤔 Зачем такие сложные смысловые конструкции с "паттернами" и другими умными словами, если адаптер это по сути методика наделения определённым интерфейсом недоступным для модификации класса? Посмотрим конечно следующие видосы. Может в этом появится смысл.
Вопрос: А как люди отнесутся к тому, что я в гламурном классе прямо реализую методы интерфейса, который будут вызывать нужные мне методы прямо на месте???? Ведь если изначальные методы останутся на месте все будет работать О_о.
Все таки не догоняю, у кого там так жопа горит чтобы интерфейс реализовать, вон бедные разрабы паттерн даже придумали чтобы ему угодить, а ведь если нет интерфейса - нет проблем.
Да уж ну и объяснение. Я сомневаюсь что "маленьким" нужен весь этот стёб. Чтобы понять хоть какой то паттерн нужен нормальный пример. Спросят тебя на собеседовании : напишите демонстрацию этого патерна. А у тебя и пф... Только кисокласс в голове...
Да мы ток посмотреть... Оу... а вот эту публичную переменную я бы "так" назвал... Эй... этот метод походу можно private сделать... Коммит. Пуш... сразу в мастер пусть! Ну лан. Я пошёл
Воспоминая про этот видос очень помогли на собесе, главное не ляпнуть гламурный кисо-класс :)
о, я тоже по этом видосу к собеседованию готовлюсь ))
Коротко, а главное доступно. Лойс.
ОМГ! Как теперь распомнить КИСОКЛАСС))) Подача материала - топчик! Спасибо за столь крутое видео. Полагаю, вы многим помогли с пониманием и дальнейшим использованием этих знаний!
Я смеялся от мемов ооочень долго. Про интерпретирование термина в проблему отдельный лайк. Спасибо тебе)
Братан, хорош, давай давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот по чаще
Не перестаю удивляться простоте повествования ... (если не считать первые секунды, когда зачитывается определение)
Офигеть, это реально круто объяснено! Автор - ты молодец!
Коротко и ясно! Спасибо большое, но хотелось бы еще видео по паттернам :)
Супер! И настроение поднял, и тему усвоил. Отличный формат!
На мой взгляд лучше второй вариант:
При первом - все публичные методы и переменные объекта класса родителя будут доступны.
При втором подходе (это ж композиция называется) ничего не светится да и жить легче.
Разве интерфейс не будет их инкапсулировать в первом случае?
Зависит от того, как сокрыты методы - private или protected, разве нет?
Модификаторы наследования есть. Или это в плюсах только?
во врором случае тоже все доступно для екземплара созданного класа
Я слишком экстремально жду следующий ролик.
Можете сделать видео по Entity Framework? Очень крутая тема, можно многое рассказать на ее примере, и про множества и про интерфейсы и все все все.
ахахах огонь конечно)))) с юморком)) инфа конечно не разжевана и приходится пересматривать по сто раз... но зато доходит так или иначе и смотреть в кайф такие видосы
Забавно, у меня был похожий кейс, но я таки додумался запилить адаптер, не зная, что использовал сей неведомый паттерн %)
Так с половиной паттернов у людей и происходит. Когда Тебе решение вдруг не кажется костыльным наконец - выясняется что есть такой паттерн. Паттерны это опыт и боль тех, кто прошел путь ранее
Безумно крутая подача, спасибо огромное!
Круто!
Будет продолжение по паттернам?
Второй вариант ИМХО часто лучше, так как поможет избежать возможной проблемы в будущем, когда потребуется отнаследовать, а уже уппс(множественное наследование классов есть только в паре языков). Тут очень важным критерием выбора является возможность использования других методов кисокласса. В этом случае первый лучше.
множественное наследование тоже пораждает кучу ромбовидных связей, несостыковки, одинаковые названия и т.п., лучше не юзать эту фичу. второй вариант мне показался юзабельнее
грубо говоря адаптер - прокладка между интерфейсом и реализуемым классом
эхх, а ведь когда то видео эксрим цоде были реально полезны
Просто замечательно, просто, понятно и моментами смешно)
1:01 ухахахахахахахх))) в тему)))
Как то сложно. Вот простое объяснение:
"Адаптер - это структурный паттерн проектирования, который позволяет объектам с несовместимыми интерфейсами работать вместе."
супер объяснение, моожноо было ток в конце показать полностью uml схемку)
Сегодня впервые наткнулся на твой канал. Можно сказать что я не "Маленький и тупой", я только родился, к тому же без мозгов)))) Так вот, посмотрел видео про интерфейсы. Вроде понял. Посмотрел видео интерфейсы на практике, там столько всего, что я только запутался, голова чуть ли не взорвалась и я уже стал сомневаться, что понимаю, что такое интерфейс. Но тут после просмотра, этого видео, осознал, что все понял. Странная хрень твориться......
Спасибо, все просто, понятно и главное - элегантно)
Красавцы, мне нравится лойс )
Это шедевр
Мужик, я от раздумий как реализовать одну механику в игре, свои мозги в желе превратил, а оказываеться её можно настолько изично с помощью этой штуки сделать
за дотку сразу лайк мгновенно :3
Нужно больше видео по паттернах!
Офигеть)) спасибо))
Царски рассказано. Спасибо!!!!!
четкий гайд
я синьор помидор, наконец-то все паттерны выучу ))
Microsoft досих пор чтут традиции 0:46
Весело получилось)
Материал огонь, я хоть изучаю РНР но все же сморю видос и делаю на РНР и результаты вдвойне радуют... Продолжение нужно однозначно!!! Кому интересен пример на РНР вот он: interface IRequester
{
public function send(string $message): void;
}
class Requester
{
public function sendRequest(string $message): void
{
echo "Отправляем сообщение: $message
";
}
}
$objectRequester = new Requester();
$objectRequester->sendRequest('Привет мир!!!');
// Реализация через Класс
class Adapter1 extends Requester implements IRequester
{
public function send(string $message): void
{
$this->sendRequest($message);
}
}
$objectAdapter1 = new Adapter1();
$objectAdapter1->send('Паттерн Адаптер (Adapter1)');
Лайк за Ёжика))
Спасибо!!
То есть, вместо того, чтобы менять шестерёнки в музыкальной шкатулке на шестерёнки с ручками (которые там не предусмотрены), мы просто приделываем к старым шестерёнкам ручки
пздц. Даже я понял это
Огромное спасибо
0:46 windows 11: 🗿
Спасибо, все очень доступно.
Получается, что во втором варианте еще и sealed класс можно так модифицировать, а первый вариант такой возможности не даст.
У мене просто бракує слів! Дякую вам за таке пояснення! Насміялася та ще й патерн зрозуміла!
Мощь!!
Ну ок, реализую я этот адаптер. А потом в коде я буду использовать получается только конректно кисо-класс там, где нужно исопльзовать возможности того интерфейса, а родительский класс и тот код, где он применялся не нужно будет трогать?
Годно!
спасибо
Нехрена не понял, зачем нужен этот патерн, когда есть extantion метод
Гламурный кисоклас
А без интерфейса если, то все равно же адаптер ? Идея же таже
простым людям непонятно
Серьезно? Вот эта хрень - и есть паттерны?..
тогда я их изначально знаю, по дефолту -_-
большинство используют паттерны и не догадываются об этом)
Классный урок. спс
Странная оговорка относительно варианта не через наследование, а через композицию.
А наследование как решение задачи не катит?
Так так и реализовали
Как часто можно встретить такую ситуацию в реальном проекте, что придется использовать Паттерн адаптер?
реально нужно просто запомнить как это делается. через пару лет работы ты уже не думаешь "Так , вот тут я буду применять адаптер ". Ты просто по умолчанию так пишешь. Это как пдд и вождение: если спросить у водителя с опытом лет 10 какое то правило , то он навряд ли процитирует его буква в букву , но все равно будет соблюдать , т.к просто привык
а если интерфейса нет все? Адаптер не случится?
Тот случай, когда всегда это используешь и даже не знаешь, что у этого есть название)))
А почему в данном примере нельзя сделать наследование нашего класса Requster с методом SendRequest() нельзя унаследовать от нужного нам интерфейса ISender с методом Send() и просто реализовать этот метод Send() внутри класса Requster, чтоюы в этом методе также вызывался метод SendRequest() ?
Представь, что Requester - старый, давно устоявшийся в системе класс, который никак менять нельзя, иначе всё сломается. Adapter нужен, чтобы обернуть этот класс для получения нового функционала, который доступен в интерфейсе ISender.
Например, представь давно существующий класс List. Ты не можешь и не должен менять его и добавлять туда что-то, но ты можешь создать Adapter для работы с этим классом, например для добавления 3-х элементов в одной операции в каком-нибудь методе add3Elements(el1, el2, el3).
Надеюсь понятно объяснил
посмотри черз комент выше
Эээ, типа надо просто зафигачить класс и отнаследоваться?!))))) в питоне, это конечно жоподробильня, которая только усложняет код(я про интерфейсы), тем не менее - очень интересно👌
Мне кажется, через экземпляр лучше
Если правильно понял, то это аналог декоратора python
неа. Декоратор (а это паттерн, не только фича в Python) изменяет поведение безотносительно добавления интерфейса в недоступный для изменения класс. Т.е., там мы подсовываем (декорируем) исходный класс/методы некоей функциональностью, но новый интерфейс можем и не добавлять
Какого чёрта, я не зная с# понимаю абсолютно всё, что здесь написано, но я знаю с/с++ и думаю, а сложно ли мне будет изучать с#.....
чёт я не понял 🤔 Зачем такие сложные смысловые конструкции с "паттернами" и другими умными словами, если адаптер это по сути методика наделения определённым интерфейсом недоступным для модификации класса?
Посмотрим конечно следующие видосы. Может в этом появится смысл.
Использовать чтоб в доту играть?
Кисоклассс
Я всегда делал через жопку :)
в С++ это абстрактный класс я правильно понимаю ?
Почти. Это абстрактный класс у которого нет полей и все методы публичные+ чисто-виртуальные.
ух ты как понятно то)
Спасибо. А кисокласс это что?
Вопрос: А как люди отнесутся к тому, что я в гламурном классе прямо реализую методы интерфейса, который будут вызывать нужные мне методы прямо на месте????
Ведь если изначальные методы останутся на месте все будет работать О_о.
Киса-класс спрятан в dll, твои действия?
@@n_raven Можно нихуйя не делать?
Дак этож декоратор из питона, что ты тут непонятными словами ругаешься, интерфейсы какие-то выдумал, наследование, что вообще?
Ахуенно!
Я не понимаю зачем учить паттерны, какие-то фреймворки (в случае с js), если ещё не выучен и не отточен нативный язык программирования
Гэроям Слава!
Все таки не догоняю, у кого там так жопа горит чтобы интерфейс реализовать, вон бедные разрабы паттерн даже придумали чтобы ему угодить, а ведь если нет интерфейса - нет проблем.
Да уж ну и объяснение. Я сомневаюсь что "маленьким" нужен весь этот стёб. Чтобы понять хоть какой то паттерн нужен нормальный пример. Спросят тебя на собеседовании : напишите демонстрацию этого патерна. А у тебя и пф... Только кисокласс в голове...
приведен же пример в начале
@@gaijin_nnsu и в конце, отличные примеры)
Лезть в чужой код...извращенцы.
Да мы ток посмотреть...
Оу... а вот эту публичную переменную я бы "так" назвал...
Эй... этот метод походу можно private сделать...
Коммит.
Пуш... сразу в мастер пусть!
Ну лан. Я пошёл
спасибо