Шаблоны разработки. ООП и основы UML

Обновленный курс GRASP and GoF Design patterns - bit.ly/3m8T19A
💪 ПРОКАЧАЙ СВОИ ХАРД-СКИЛЛЫ ЗА 2 МЕСЯЦА!
Вводная лекция курса "Шаблоны разработки программного обеспечения". Основы ООП. Основы UML. Плейлист: • Шаблоны разработки. Вв...
Все материалы курса лекций (включая конспект лекций) на моем канале на SlideShare: www.slideshare.net/SergeyNemch...
Изучение C#/.Net bit.ly/2P5JKuM
Изучение Blockchain developer bit.ly/2KF1Y60
Сайт учебного центра: bit.ly/2N3ckw6

[@hameltomor]

Это самые лучшие лекция которые я только видел! Легко, доступно и понятно. Большое Вам спасибо)

[@danielginzburg2924]

Сергей вы молодец! Вы один из лучших лекторов. Большое вам спасибо!

[@dmytrodemydenko6732]

Как ребятам повезло. Педагог с большой буквы

[@AlluringStuff]

Смотрю на одном дыхании! Лучшей подачи материала я еще не видел!

[@denistalko6585]

Прекрасные лекции! Спасибо огромное, очень интересно и полезно! Рассказывается доступно, живо, невероятно интересно. Очень классно!

[@dmitrypopov5056]

Большое спасибо за лекции, они шикарны.

[@serjchernyh8715]

Еще раз огромное спасибо за лекции.Век живи, век учись.Многое для себя открыл.Понял, что был "хитрым программистом" :)

[@viktorsoroka4510]

Здорово! И с юмором и, что самое главное, все по делу. Спасибо)

[@olek_tar]

Классная лекция! Спасибо!

[@dutnum5766]

Обозначение уровня доступа на UML диаграммах: + public - private # protected ~ package

[@AnaRxistBoD]

internal? protected internal? private protected? sealed?

[@hristy-A]

@@AnaRxistBoD package - это и есть internal, только package - это абстрактно, на уровне диаграмм UML, а internal на уровне конкретного языка. Другие модификаторы доступа можно получить с помощью комбинации имеющихся (не лучший вариант) или использовать диаграммы для конкретного языка, где уже придуманы свои обозначения.

[@user-cc2mi5jh3y]

Полиморфизм - это поддержка нескольких реализаций на основе общего интерфейса. Matt Zandstra

[@Das.Kleine.Krokodil]

Слишком общо. Не передаёт суть

[@SHURmandroid]

Спасибо за "продолжение мучений"... :-)

[@YasnaKo]

Вывела для себя тезис: - Наследование строить снизу вверх, а не сверху вниз.

[@farenoy6848]

Я ❤️ Сергея Немчинского

[@cyrilanisimov]

аааааа! волосатый Немчинский!! Привет из 2021

[@kolobokhexopod5423]

Перегрузка методов и функций (в случае C++) также считается полиморфизмом, но только статическим (compile time). Виртуальные методы класса обеспечивают динамический полиморфизм (runtime). Полиморфизм - это когда один и тот-же кусок кода выполняет разную работу в зависимости от внешних факторов - конкретного типа объекта скрывающегося за указателем на базовый класс, типа аргумента при вызове функции, и тп. Заменили один указатель на базовый класс на другой, и при вызове виртуальной функции через этот указатель код уже делает что-то другое. Или при вызове функции поменяли аргумент одного типа на аргумент другого типа - получили совсем другое поведение (пример статического полиморфизма). Я понимаю полиморфизм, как способность оперировать объектами разных типов в обобщенном виде, способность писать общие алгоритмы для обработки объектов являющихся потомками некоторого базового класса. Инкапсуляция позволяет поддерживать объекты и части системы в непротиворечивом состоянии. Наследование - инструмент, позволяющий обобщать свойства и поведение объектов. Строго говоря, полиморфизм не является прерогативой объектно-ориентированного подхода. Можно использовать полиморфизм программируя на чистом C. Например, используя указатели на функции можно получить такой-же эффект как от полиморфизма в ОО языках.

[@0imax]

Да, в книжках по C++ перегрузку часто называют статическим полиморфизмом. Но мне кажется, не стОит смешивать понятия "перегрузка" и "полиморфизм", дабы не было путаницы. Перегрузка обычно используется, чтобы одной и той же функции можно было скормить разные типы данных, но при этом действия над ними производились одинаковые или очень похожие. Полиморфизм в контексте ООП преследует другие цели - менять поведение *объекта* в зависимости от типа самого объекта, при том что входные данные одного типа. Можно построить полиморфизм на перегрузке, но это будет коряво и бессмысленно)

[@NorthSea-xb7jk]

сабскрайбнулся, досмотрю , оценю

[@Das.Kleine.Krokodil]

Спасибо!

[@user-ff3ez4pv6e]

6 лет прошло! До сих пор актуально

[@codingfox]

и не говори)

[@user-yg8mt9fy8l]

Лекция вроде от 2008 года

[@0imax]

И будет ещё лет 20 минимум.

[@rusnickk]

спасибо за интересную лекцию, возник такой вопрос: если для получения price необходимо обращение к базе данных для чего используется экземпляр класса, скажем, DataBaseProvider, до как передается ссылка на этот объект экземпляру OderItem?

[@faridnadirov5472]

Лучший лектор!

[@global_silence2623]

Правильно ли я понял, что "Агрегацию" нужно рисовать между классами А и В ромбиком в сторону класса А, если А содержит поле List? И еще. Верно ли я понимаю, что если мы воспринимаем обычную стрелочку, как создание экземпляра класса и вызова каких-то методов, то стартовый класс main может быть просто утыкан этими обычными стрелками?

[@MrSergeyUSA]

Спасибо за видео! Скажите по вашему какое отношение больше подходит для классов Директория и Файл?

[@MrSergeyUSA]

+Sergey Nemchinsky с точки зрения может ли существовать абстрактный файл без абстрактного каталога вообще, если каталогами считать все устройства с их корневыми папками.

[@Ma_X64]

На уровне файловой системы всё есть файл. и каталог - тоже файл, и порт - файл (в линухе уж точно), и принтер - файл. Тем не менее, в ОС ведь всегда существует корневая директория. Потому что это удобно и с точки зрения пользователя выглядит логично. Поэтому нужно выбирать тот вариант, который будет удобен с точки зрения конечного пользователя того, что ты пишешь.

[@kaynsolo]

Like!

[@Mike19910711]

Про UML. Стрелка Association показывает, что один объект (от которого идёт стрелка) содержит в поле другой объект (тот, куда направлена стрелка). Аналогичная стрелка, но прерывистая (Dependency) означает, что класс, от которого идёт стрелка, в одном из методов принимает в качестве параметра или возвращает в каком-нибудь методе объект класса, на который направлена стрелка.

[@SergeyNemchinskiy]

Я вам рассказал то, как эти стрелки будут читать ваши коллеги. Как они задуманы разработчиками - всем пофиг. Реальная жизнь говорит - вот так :) Можно ее игнорировать, но смысл?

[@fio6951]

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

[@user-lp1qt8ot9v]

На слайдах везде 2008. Сейчас актуально все?

[@user-yj8vx8ph4j]

безусловно, парадигма не стареет

[@kirillkir6268]

Все хорошо, вот только OrderItem и Good это DTO, а распределение калькуляции это нарушение Сингл Респонсибилити калькулятора)

[@sergeyltk]

А разве язык программирования (Java / c++) и способ очистки памяти является ключевым критерием в определении того, какой тип ассоциации использовать? Там вроде логический критерий, когда лучше агрегация, а когда композиция. В агрегации плюсом идёт гибкость, а в композиции - скрытие от глаз клиента деталей реализации. Ну, это моё понимание.

[@1Cry1987]

Шаблон Creator предполагает, что публичный интерфейс калькулятора будет содержать все методы, необходимые для манипулирования сокрытых классов. Хорошо. А если сокрытых классов 10? 20? Это же будет God Class, не иначе. И к тому же, если ListItem будет создаваться напрямую в Calculator, как тестировать этот код?

[@ansz237]

Разве creator не конфликтует с принципом инверсией зависимости? Каждый раз когда один класс напрямую порождает объект другого класса между ними возникает жесткая связь.

[@0imax]

Любое создание объектов нарушает IoC, поскольку в итоге всё-равно нужно явно указать конкретный класс, будь это обычное создание класса, через фабрику или ещё как-то. Так что ничего страшного в этом нарушении нет. Принципы можно и нужно нарушать, если это делается во благо, как, например, тот же Factory method нарушает принцип Low coupling: класс, создающий подклассы, знает о всех своих наследниках.

[@MrShnaiderTV]

​@@0imax Именно из-за нарушения DIP создание объектов и инкапсулируется в фабрики. Принцип creator действительно нарушает DIP, так как создает объекты в runtime, а не на этапе инициализации программы (Clean code, глава 11). Фабричный же метод (в оригинале) DIP не нарушает, так как все зависимости в самой программе направлены на абстракции, а реализацию создания объекта можно подменить, подставив другую реализацию создающего объекта (фабрики). Если реализовывать паттерн, как рассказывал Сергей (через статичные методы), то да, это нарушение DIP. Но это и не оригинальная реализация паттерна, а лишь его интерпретация

[@1Cry1987]

А лектор фанат группы Amaranthe ;)

[@Megapixxxell]

ссылка на материалы лекций не SlideShare не работает =(

[@helavin4ik]

Работает, только что скачал

[@user-pg8ry1tm3t]

Вообще-то жесткая зависимость - агрегация… has a. Relationship “is a” less then aggregation

[@leon4uk]

Да никто не спрашивает на собеседованиях к примеру что такое полиморфизм и вообще про парадигмы. Все пытаются спросить подковыристый вопрос даже не на тему абстракции, а типа - есть хомяк, а утром его нет. Куда делся хомяк. Вот смотря как ответишь, так и возьмут тебя на работу. А еще спросят про китайский язык.

[@maddjimi8854]

Народ вот хвалит, а я так думаю зря... Объяснение, например, полиморфизма крайне плохое и косноязычное. Если человек уже не знает, что это такое ни хрена не будет понятно.

[@user-ee5if7ru4g]

суть курса в том, что люди уже знают основы

[@0imax]

Mad Djimi Курс паттернов следует смотреть, зная основы ООП, а лучше проработав пару лет, чтобы было понятно вообще о чём речь. Не зря этот курс находится у Сергея в плейлисте "для опытных разработчиков" :)

[@user-gw6df6ns7e]

Ну полиморфизм - это холивар. А параметризованный тип - это полиморфизм. А если это реализовано через мономорфизацию? А оверлоадинг тоже можно отнести к полиморфизму?

[@libx75]

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

[@g19m74]

Заканали фоновые бла бла бла