@@AnaRxistBoD package - это и есть internal, только package - это абстрактно, на уровне диаграмм UML, а internal на уровне конкретного языка. Другие модификаторы доступа можно получить с помощью комбинации имеющихся (не лучший вариант) или использовать диаграммы для конкретного языка, где уже придуманы свои обозначения.
Перегрузка методов и функций (в случае C++) также считается полиморфизмом, но только статическим (compile time). Виртуальные методы класса обеспечивают динамический полиморфизм (runtime). Полиморфизм - это когда один и тот-же кусок кода выполняет разную работу в зависимости от внешних факторов - конкретного типа объекта скрывающегося за указателем на базовый класс, типа аргумента при вызове функции, и тп. Заменили один указатель на базовый класс на другой, и при вызове виртуальной функции через этот указатель код уже делает что-то другое. Или при вызове функции поменяли аргумент одного типа на аргумент другого типа - получили совсем другое поведение (пример статического полиморфизма). Я понимаю полиморфизм, как способность оперировать объектами разных типов в обобщенном виде, способность писать общие алгоритмы для обработки объектов являющихся потомками некоторого базового класса. Инкапсуляция позволяет поддерживать объекты и части системы в непротиворечивом состоянии. Наследование - инструмент, позволяющий обобщать свойства и поведение объектов. Строго говоря, полиморфизм не является прерогативой объектно-ориентированного подхода. Можно использовать полиморфизм программируя на чистом C. Например, используя указатели на функции можно получить такой-же эффект как от полиморфизма в ОО языках.
Да, в книжках по C++ перегрузку часто называют статическим полиморфизмом. Но мне кажется, не стОит смешивать понятия "перегрузка" и "полиморфизм", дабы не было путаницы. Перегрузка обычно используется, чтобы одной и той же функции можно было скормить разные типы данных, но при этом действия над ними производились одинаковые или очень похожие. Полиморфизм в контексте ООП преследует другие цели - менять поведение *объекта* в зависимости от типа самого объекта, при том что входные данные одного типа. Можно построить полиморфизм на перегрузке, но это будет коряво и бессмысленно)
Про UML. Стрелка Association показывает, что один объект (от которого идёт стрелка) содержит в поле другой объект (тот, куда направлена стрелка). Аналогичная стрелка, но прерывистая (Dependency) означает, что класс, от которого идёт стрелка, в одном из методов принимает в качестве параметра или возвращает в каком-нибудь методе объект класса, на который направлена стрелка.
Я вам рассказал то, как эти стрелки будут читать ваши коллеги. Как они задуманы разработчиками - всем пофиг. Реальная жизнь говорит - вот так :) Можно ее игнорировать, но смысл?
спасибо за интересную лекцию, возник такой вопрос: если для получения price необходимо обращение к базе данных для чего используется экземпляр класса, скажем, DataBaseProvider, до как передается ссылка на этот объект экземпляру OderItem?
Правильно ли я понял, что "Агрегацию" нужно рисовать между классами А и В ромбиком в сторону класса А, если А содержит поле List? И еще. Верно ли я понимаю, что если мы воспринимаем обычную стрелочку, как создание экземпляра класса и вызова каких-то методов, то стартовый класс main может быть просто утыкан этими обычными стрелками?
+Sergey Nemchinsky с точки зрения может ли существовать абстрактный файл без абстрактного каталога вообще, если каталогами считать все устройства с их корневыми папками.
На уровне файловой системы всё есть файл. и каталог - тоже файл, и порт - файл (в линухе уж точно), и принтер - файл. Тем не менее, в ОС ведь всегда существует корневая директория. Потому что это удобно и с точки зрения пользователя выглядит логично. Поэтому нужно выбирать тот вариант, который будет удобен с точки зрения конечного пользователя того, что ты пишешь.
А разве язык программирования (Java / c++) и способ очистки памяти является ключевым критерием в определении того, какой тип ассоциации использовать? Там вроде логический критерий, когда лучше агрегация, а когда композиция. В агрегации плюсом идёт гибкость, а в композиции - скрытие от глаз клиента деталей реализации. Ну, это моё понимание.
Шаблон Creator предполагает, что публичный интерфейс калькулятора будет содержать все методы, необходимые для манипулирования сокрытых классов. Хорошо. А если сокрытых классов 10? 20? Это же будет God Class, не иначе. И к тому же, если ListItem будет создаваться напрямую в Calculator, как тестировать этот код?
Разве creator не конфликтует с принципом инверсией зависимости? Каждый раз когда один класс напрямую порождает объект другого класса между ними возникает жесткая связь.
Любое создание объектов нарушает IoC, поскольку в итоге всё-равно нужно явно указать конкретный класс, будь это обычное создание класса, через фабрику или ещё как-то. Так что ничего страшного в этом нарушении нет. Принципы можно и нужно нарушать, если это делается во благо, как, например, тот же Factory method нарушает принцип Low coupling: класс, создающий подклассы, знает о всех своих наследниках.
@@0imax Именно из-за нарушения DIP создание объектов и инкапсулируется в фабрики. Принцип creator действительно нарушает DIP, так как создает объекты в runtime, а не на этапе инициализации программы (Clean code, глава 11). Фабричный же метод (в оригинале) DIP не нарушает, так как все зависимости в самой программе направлены на абстракции, а реализацию создания объекта можно подменить, подставив другую реализацию создающего объекта (фабрики). Если реализовывать паттерн, как рассказывал Сергей (через статичные методы), то да, это нарушение DIP. Но это и не оригинальная реализация паттерна, а лишь его интерпретация
Да никто не спрашивает на собеседованиях к примеру что такое полиморфизм и вообще про парадигмы. Все пытаются спросить подковыристый вопрос даже не на тему абстракции, а типа - есть хомяк, а утром его нет. Куда делся хомяк. Вот смотря как ответишь, так и возьмут тебя на работу. А еще спросят про китайский язык.
Народ вот хвалит, а я так думаю зря... Объяснение, например, полиморфизма крайне плохое и косноязычное. Если человек уже не знает, что это такое ни хрена не будет понятно.
Mad Djimi Курс паттернов следует смотреть, зная основы ООП, а лучше проработав пару лет, чтобы было понятно вообще о чём речь. Не зря этот курс находится у Сергея в плейлисте "для опытных разработчиков" :)
Ну полиморфизм - это холивар. А параметризованный тип - это полиморфизм. А если это реализовано через мономорфизацию? А оверлоадинг тоже можно отнести к полиморфизму?
Это самые лучшие лекция которые я только видел! Легко, доступно и понятно. Большое Вам спасибо)
Сергей вы молодец! Вы один из лучших лекторов. Большое вам спасибо!
Смотрю на одном дыхании! Лучшей подачи материала я еще не видел!
Прекрасные лекции! Спасибо огромное, очень интересно и полезно! Рассказывается доступно, живо, невероятно интересно. Очень классно!
Как ребятам повезло. Педагог с большой буквы
Еще раз огромное спасибо за лекции.Век живи, век учись.Многое для себя открыл.Понял, что был "хитрым программистом" :)
Большое спасибо за лекции, они шикарны.
Здорово! И с юмором и, что самое главное, все по делу. Спасибо)
Полиморфизм - это поддержка нескольких реализаций на основе общего интерфейса. Matt Zandstra
Слишком общо. Не передаёт суть
Обозначение уровня доступа на UML диаграммах:
+ public
- private
# protected
~ package
internal?
protected internal?
private protected?
sealed?
@@AnaRxistBoD package - это и есть internal, только package - это абстрактно, на уровне диаграмм UML, а internal на уровне конкретного языка. Другие модификаторы доступа можно получить с помощью комбинации имеющихся (не лучший вариант) или использовать диаграммы для конкретного языка, где уже придуманы свои обозначения.
Спасибо за "продолжение мучений"... :-)
аааааа! волосатый Немчинский!! Привет из 2021
Вывела для себя тезис:
- Наследование строить снизу вверх, а не сверху вниз.
Перегрузка методов и функций (в случае C++) также считается полиморфизмом, но только статическим (compile time). Виртуальные методы класса обеспечивают динамический полиморфизм (runtime). Полиморфизм - это когда один и тот-же кусок кода выполняет разную работу в зависимости от внешних факторов - конкретного типа объекта скрывающегося за указателем на базовый класс, типа аргумента при вызове функции, и тп. Заменили один указатель на базовый класс на другой, и при вызове виртуальной функции через этот указатель код уже делает что-то другое. Или при вызове функции поменяли аргумент одного типа на аргумент другого типа - получили совсем другое поведение (пример статического полиморфизма).
Я понимаю полиморфизм, как способность оперировать объектами разных типов в обобщенном виде, способность писать общие алгоритмы для обработки объектов являющихся потомками некоторого базового класса.
Инкапсуляция позволяет поддерживать объекты и части системы в непротиворечивом состоянии.
Наследование - инструмент, позволяющий обобщать свойства и поведение объектов.
Строго говоря, полиморфизм не является прерогативой объектно-ориентированного подхода. Можно использовать полиморфизм программируя на чистом C. Например, используя указатели на функции можно получить такой-же эффект как от полиморфизма в ОО языках.
Да, в книжках по C++ перегрузку часто называют статическим полиморфизмом.
Но мне кажется, не стОит смешивать понятия "перегрузка" и "полиморфизм", дабы не было путаницы.
Перегрузка обычно используется, чтобы одной и той же функции можно было скормить разные типы данных, но при этом действия над ними производились одинаковые или очень похожие.
Полиморфизм в контексте ООП преследует другие цели - менять поведение *объекта* в зависимости от типа самого объекта, при том что входные данные одного типа.
Можно построить полиморфизм на перегрузке, но это будет коряво и бессмысленно)
Классная лекция! Спасибо!
Я ❤️ Сергея Немчинского
Про UML. Стрелка Association показывает, что один объект (от которого идёт стрелка) содержит в поле другой объект (тот, куда направлена стрелка). Аналогичная стрелка, но прерывистая (Dependency) означает, что класс, от которого идёт стрелка, в одном из методов принимает в качестве параметра или возвращает в каком-нибудь методе объект класса, на который направлена стрелка.
Я вам рассказал то, как эти стрелки будут читать ваши коллеги. Как они задуманы разработчиками - всем пофиг. Реальная жизнь говорит - вот так :) Можно ее игнорировать, но смысл?
Спасибо!
сабскрайбнулся, досмотрю , оценю
6 лет прошло!
До сих пор актуально
и не говори)
Лекция вроде от 2008 года
И будет ещё лет 20 минимум.
Лучший лектор!
спасибо за интересную лекцию, возник такой вопрос: если для получения price необходимо обращение к базе данных для чего используется экземпляр класса, скажем, DataBaseProvider, до как передается ссылка на этот объект экземпляру OderItem?
Правильно ли я понял, что "Агрегацию" нужно рисовать между классами А и В ромбиком в сторону класса А, если А содержит поле List?
И еще. Верно ли я понимаю, что если мы воспринимаем обычную стрелочку, как создание экземпляра класса и вызова каких-то методов, то стартовый класс main может быть просто утыкан этими обычными стрелками?
На слайдах везде 2008. Сейчас актуально все?
безусловно, парадигма не стареет
Спасибо за видео!
Скажите по вашему какое отношение больше подходит для классов Директория и Файл?
+Sergey Nemchinsky с точки зрения может ли существовать абстрактный файл без абстрактного каталога вообще, если каталогами считать все устройства с их корневыми папками.
На уровне файловой системы всё есть файл. и каталог - тоже файл, и порт - файл (в линухе уж точно), и принтер - файл. Тем не менее, в ОС ведь всегда существует корневая директория. Потому что это удобно и с точки зрения пользователя выглядит логично. Поэтому нужно выбирать тот вариант, который будет удобен с точки зрения конечного пользователя того, что ты пишешь.
Все хорошо, вот только OrderItem и Good это DTO, а распределение калькуляции это нарушение Сингл Респонсибилити калькулятора)
А разве язык программирования (Java / c++) и способ очистки памяти является ключевым критерием в определении того, какой тип ассоциации использовать? Там вроде логический критерий, когда лучше агрегация, а когда композиция. В агрегации плюсом идёт гибкость, а в композиции - скрытие от глаз клиента деталей реализации. Ну, это моё понимание.
Шаблон Creator предполагает, что публичный интерфейс калькулятора будет содержать все методы, необходимые для манипулирования сокрытых классов. Хорошо. А если сокрытых классов 10? 20? Это же будет God Class, не иначе.
И к тому же, если ListItem будет создаваться напрямую в Calculator, как тестировать этот код?
Like!
Разве creator не конфликтует с принципом инверсией зависимости? Каждый раз когда один класс напрямую порождает объект другого класса между ними возникает жесткая связь.
Любое создание объектов нарушает IoC, поскольку в итоге всё-равно нужно явно указать конкретный класс, будь это обычное создание класса, через фабрику или ещё как-то.
Так что ничего страшного в этом нарушении нет. Принципы можно и нужно нарушать, если это делается во благо, как, например, тот же Factory method нарушает принцип Low coupling: класс, создающий подклассы, знает о всех своих наследниках.
@@0imax Именно из-за нарушения DIP создание объектов и инкапсулируется в фабрики. Принцип creator действительно нарушает DIP, так как создает объекты в runtime, а не на этапе инициализации программы (Clean code, глава 11). Фабричный же метод (в оригинале) DIP не нарушает, так как все зависимости в самой программе направлены на абстракции, а реализацию создания объекта можно подменить, подставив другую реализацию создающего объекта (фабрики). Если реализовывать паттерн, как рассказывал Сергей (через статичные методы), то да, это нарушение DIP. Но это и не оригинальная реализация паттерна, а лишь его интерпретация
ссылка на материалы лекций не SlideShare не работает =(
Работает, только что скачал
А лектор фанат группы Amaranthe ;)
Вообще-то жесткая зависимость - агрегация… has a. Relationship “is a” less then aggregation
Да никто не спрашивает на собеседованиях к примеру что такое полиморфизм и вообще про парадигмы. Все пытаются спросить подковыристый вопрос даже не на тему абстракции, а типа - есть хомяк, а утром его нет. Куда делся хомяк. Вот смотря как ответишь, так и возьмут тебя на работу. А еще спросят про китайский язык.
Народ вот хвалит, а я так думаю зря...
Объяснение, например, полиморфизма крайне плохое и косноязычное.
Если человек уже не знает, что это такое ни хрена не будет понятно.
суть курса в том, что люди уже знают основы
Mad Djimi
Курс паттернов следует смотреть, зная основы ООП, а лучше проработав пару лет, чтобы было понятно вообще о чём речь.
Не зря этот курс находится у Сергея в плейлисте "для опытных разработчиков" :)
Ну полиморфизм - это холивар. А параметризованный тип - это полиморфизм. А если это реализовано через мономорфизацию? А оверлоадинг тоже можно отнести к полиморфизму?
Заканали фоновые бла бла бла
раз уж начал - досмотрел до конца. но больше никаких лекций от этого автора ни за что.