Жду пока он скажет - "Я больше не Сергей Немчинский, теперь я имплементирую интерфейс Сергея Немчинского!" )) Спасибо за видео, как всегда доходчиво и понятно
Очень сумбурное объяснение. Если бы сам не знал бы принципы solid, то из этого видео возможно не понял бы. Ну и да, доску нужно ближе и маркеры темнее или вообще перейти на запись видео с экрана, с электронной доской. В любом случае спасибо за видео! Очень полезно послушать многие вещи, то как их другие понимают.
Зачем же вы бумагу переводите. Доску специально делают такую чтобы можно было легко стереть каракули. Куда эта бумага потом попадает? На полигоны и складируется? На ней еще ничего и не видно, и скрип неприятный. Откуда вы такие беретесь то, вроде видео 2020 года
Непонятно, почему я не могу добавить метод в существующий класс, чем плодить новые классы наследованием и там добавлять? И если правок будет много, то это сколько ж наследований будет.
Да ерунда, конечно. Я бы так сказал, что добавлять можно, а вот менять - проблемно, т.к. зависимые классы и клиенты тоже придётся менять. Проблема может быть в интерфейсе. Если туда добавить метод, его придётся добавлять во все наследники.
Перечитал Роберта Мартина. Специально, чтобы убедиться в том, что я правильно понимаю Принцип Отркытоти / Закрытости (OCP). . Так, вот, этот принцип не совсем про Классы и Интерфейсы, наследование и реализацию, и уж тем более, не про "замочки" на классах. Это все, конечно правильно, но, это все частные способы вносить изменения в код, который, кстати, не обязательно соответствует OCP. И применение к нему описанных техник изменения сохранит это свойство кода. . OCP о том, что следуя SRP мы также должны учитывать, что отдельные подзадачи могут иметь разные решения и выделять соответствующие абстракции, защищая этим самым решение общей задачи от изменений, и делая такое решение открытым для расширения. Т.е. OCP -- это про декомпозицию кода. Именно, следуя OCP мы должны выделить наши зависимости, т.е. проанализировать, какие подзадачи могут иметь альтернативные решения, оценить вероятность такого измнения, что в свою очередь позволит не плодить лишнии абстракции. . На простом примере: Мы делаем функцию сортировку и используем в алгоритме простую конструкцию: a < b, чтобы понять надо ли нам поменять элементы местами или нет. Мы находимся в рамках SRP (т.е. наш алгоритм имеет одного Актора, решает одну задачу). Но, если нам надо будет реализовать сортировку уже по возрастанию (убыванию), то нам надо будет менять алгоритм, чего собственно мы и хотим избежать. . Так вот OCP говорит нам о том, что наш алгоритм сортировки должен абстрагироваться от реализации отношения порядка (что помимо всего прочего позволит абстрагироваться еще и по типу данных элементов коллекции). . Видео из объяснения OCP вылилось в расказ про DIP, где зависимости нам уже даны. OCP -- про выявление зависимостей и создание абстракций. . На 9:20 Сергей дает пример Клиентского класса и Серверного класса, и говорит о том, что это нарушает OCP потому, что мы не можем расширить их взаимодействие. И здесь очень опасная и хитрая ошибка, которая заключается в том, что нам не надо расширять это взаимодействие. Нам надо расширить функциональность, а не взаимодействие отдельных двух компонентов. . В заключении, перефразирую Кота Матроскина: - чтобы инвертировать что-нибудь "ненужное", сначала надо абстрагироваться по этому "ненужному", а мы об этом в видео не говорим ...
"Видео из объяснения OCP вылилось в расказ про DIP, где зависимости нам уже даны. OCP -- про выявление зависимостей и создание абстракций." - спасибо за идею!
@@ivanandreev9571 заменить "a < b" на "compare(a, b) < 0" -- это будет OCP. Это позволит изменять порядок сортировки, не меняя при этом сам алгоритм сортировки. А потом по DIP надо принимать функцию conpare на вход влгоритма сортировки.
самый противоречивый принцип на мой взгляд, с точки зрения практики это же жопа(извините), открываешь такой проект, заходишь в интерфейс, смотришь его реализации, а там или композиции или наследники друг друга, и их 5 штук например и хочешь себе выстрелить в голову... по-моему лучше сразу рефакторить нафиг, и делать один нормальный класс если это реально расширения одного направления
Не, а вдруг ещё кто-то не знает? И заметьте, Сергей старается протараторить это как можно быстрее. Хотя уже можно просто рисовать баннер с фио и регалиями, как в программе «Время». 100К уже есть, зачем им слушать это постоянно? Чтоб в подкорку вбивалось? Ну мякше надо, нежнее.
Не очень понятно. А как расширять функциональность, если интерфейс менять нельзя? А если клиенту нужны новые методы, или старые методы с другой сигнатурой?
Не понял насчёт трактовки от Мартина: нам что, нужно создавать новый класс, который заново будет имплементировать интерфейс, только поведение уже будет другое, чем у класса, со старой реализацией?
@@SergeyNemchinskiy если не унаследоваться от старого, то всё равно не понимаю. У нас есть новый класс с новой реализацией, зачем тогда сохранять старый?
@@kisurov но у нас же тогда в итоге окажется по десять обёрток над каждым классом, как с этим быть? Или предполагается, что код будет писаться сразу как надо, и изменения будут малочисленными?
А как этот принцип сочетается с тем, что бизнес требования, а за ними бизнес-логика, меняются по два раза в день и всем в принципе заранее понятно, что так и будет?
Вопрос, так а конструкция Роберта Мартина(1996 год), я не понял как там тогда "расширять" функционал, если и старый класс(функционал), и новый, зависят от одного интерфейса. как мы добавим что-т новое, если интерфейс у них один?
функционал можно только добавить но не трогая интерфейс а вот первый вариант гибче выходит, там мы наследуюем и добавляем любой функционал (в интерфейс) не нарушай базовый интерфейс ) чет Сергей не договаривает или просто на тренинг так манит )))
Подразумевается, наверное, что требуемый объект будет инициализирован или найден при необходимости. Адаптер это про другое, про создание одного интерфейса поверх другого/других для удобства использования
Так много людей которым нравиться видос и которые ничего не поняли. Я так и не понял что это на практике, даже нет никакого вывода с чёткой формулировкой что это такое. Мне просто использовать интерфейсы и работать через них или что?
Да если патерны посмотреть, тоже все сходится к использовании интерфейсов. А вообще все принцепы и патерны сводятся к тому что нужно делать так чтоб ты мог дописывать код и ничего не ломалось.
Сергей, ты случайно в конце не оговорился про IoC и Dependency Inversion? Может имел ввиду Dependency Injection, как имплементацию IoC, а используя Dependency Inversion принцип мы можем подкидывать в IoC контейнер нужные нам реализации интерфейса? В данном случае оговорка, как по мне, достаточно существенная и может ввести в заблуждение тех, кто недавно с этим столкнулся... А так все по делу. Спасибо за то что ты делаешь. Лойк!)
да, это оговорка, еще чуть раньше он принцип назвал паттерном, но если человек захочет разобраться в этой теме, данных видосов будет мало, а небольшие неточности исчезнут в процессе.
Работал в 2х компаниях дот нет джуном... омг сколь там было говна, платили хорошо, но видимо понимали что с этим легаси разбираться, и одна из этих компаний достаточно известная.
На самом деле, спасибо большое, Сергей, пересматриваю во время тренинга, правда, не у вас, к сожалению, а в епаме, но всё-таки. Во время написания кода Ваши рекомендации, когда на заднем плане идут, реально отлично помогают при рефакторинге архитектуры приложения. Пишу классы для доступа к базе данных и интерфейс, где у меня очень высокая зависимость классов друг от друга, а потом слышу с заднего плана: надо просто вынести клиентский код в интерфейс, и реально выношу его в интерфейс, и оно всё в результате отлично спроектировано получается.
dont cahch this - может я что-то не знаю но в Python нет интерфесов получается что нужно создавать абстрактные классы для того чтобы их имплементировать другими классами - но если в других языках понятно что он имплементирует то для классов вообще не очень понятно, почему нельзя делать decorator функции если она чем -то не подходит, хотя конечно это уже будет другая функция и работать она может по другому. с точки зрение истинного полиморфизма это не пойдет, зато дублирования кода никакого не будет.
Очень простое і доступное объяснение. Даже есть практический пример из жизни, что очень помогает понять. Спасибо большое! Мне очень нравится ваши видео. ☺
@@0imax хотя я на начальном этапе максимально стараюсь оптимизировать и гибкость сделать.. и уже когда проект разросья уже не трогать, а все недочеты запоминать на след проект, и потмо уже править в новом проекте.
10:10 Если посмотреть так-то по диаграмме на декторатор, то получается, что у нас циклическая зависимость Прокси от Интерфейса и Интерфейса от прокси) И мы можем вставлять абсолютно любое количество дополнительного функционала: логирование, кэширование, аутентификацию, авторизацию, аудит - поскольку они все полетят в трубу, а проекты просто не скомпилируются :D
Историческая отсылка понравилась, а вот по сути - если бы я не знал как работают SOLID принципы - то без наглядных примеров мало что понял бы из этого видео
Очень классная линейка видео про SOLID. Большое спасибо вам за это! Если можно, то можете снять также линейку видео про structural, behavioral design patterns. Хотя бы по 3 с каждого?
Я не знаю как максимально вежливо подсветить, наверное, все равно обижу спикера, но все же повторю, что исключение хезитационных пауз из речи стало бы колоссальной её оптимизацией. Ещё раз спасибо за труд. С признательностью и благодарностью.
Коллеги, дайте, пожалуйста, совет. Ну, не совет, а скорее напутствие. Во вторник я выхожу на новую работу в банк, до/переписывать на джаве/котлине некоторое древнее корпоративное кхм-кхм. До этого промышленно писал только на питоне и то совсем недолго. Джаву знаю... ну очень такое себе.
Такой вопрос: можно ли начать свою карьеру на фрилансе, а уже потом претендовать на позицию middle в it-компании спустя 1-3 года работы на фрилансе? В моем случае именно так получается, тк работаю по контракту и не могу работать официально где-либо еще, плюс ко всему время не позволит. Рассматриваю фронтенд-разработку
Смысл в принципе Майера хотя-бы в том, что ты сам определяешь интерфейс взаимодействия дочерних классов. Причём дочерние классы не просто не обязаны работать со старым вызывающим кодом, но и физически не будут с ним работать. Это должно быть очевидно такому матерому человеку как Немчинский. Во вторых, код любого метода может быть переписан при сохранении логики его работы, числа и типов его параметров и возвращаемого значения не только для исправления ошибок но и для целей оптимизации. Это не подлежит ни какому обсуждению! Это здравый смысл. Выкидывать из класса код отвечающий за сериализацию и/или сериализацию ещё глупее чем следовать принципам Solid. Немчинский у тебя яйц нет признаться, что принципы Solid говно?!
Нельзя трогать старый код, а как тогда понять что в родительском модуле есть все необходимые методы для будущего (клиентского) кода ? Или добавление методов в родительский код не будет считаться нарушением OCP, а нарушение будет тогда, когда будут переписываться уже реализованные методы ?
А как быть с MVC? Например у меня есть какой-то контроллер (класс) и что есть добавление методов в него? Изменение класса или расширение класса? Если изменение, то как мне в свой контроллер добавлять методы (экшены) ?
10:10 Как коротко объяснить разницу между Proxy и Decorator? Поменять выход стрелки. Это самое короткое и понятное объяснение без кода, которое можно использовать в любом коде где это целесообразно. Правда без знания UML понять будет сложно.
Сергей, такой вопрос, не знаете ли поменял ли Мейер первое его понимание этого принципа во втором издании в 97 годе, после того как Мартин опубликовал версию OCP в 96 году?
Благодарю за видео, только не очень понятно, как ваша установка о том. что работающему программисту не нужно прокачивать т. н. хардскиллы в свободное от работы время, увязывается с тем, что вы преподаете курс по паттернам явно не для новичков
За Сергея не отвечу, а вот сам я знаком со многими из КОВО где эти курсы проводятся и знаю многих кто после Ш++ достаточно неплохо устроились работать, плюс там отличная внутренняя атмосфера. Если вы сами мотивированны к обучению - то естественно получите хорошие знания
