2. Декомпозиция, объектно-ориентированное проектирование

compscicenter.ru/
Лекция №2 курса «Проектирование ПО» (весна 2022)
Преподаватель - Юрий Литвинов
Страница курса на сайте CS центра: bit.ly/3lLaovY

[@danilabondarenko5398]

0:00 О чем будет лекция 1:28 О сложности 4:04 Свойства сложных систем 8:24 Подходы к управлению сложностью 16:28 О модульности 19:46 Метрики качества модульных систем Coupling, Cohesion 22:16 Определение объекта 25:56 Свойства объекта 34:42 Про абстракцию 37:36 Про инкапсуляцию 39:55 Про наследование и композицию 43:23 Вопрос: Когда стоит применять наследование ? 44:34 Проблемы с наследованием в C++ 48:38 Как выделять объекты в предметной области 52:30 Изоляция сложности как источник для объектов 55:53 Изоляция возможных изменений как источник для объектов 1:03:12 Изоляция служебной функциональности как источник для объектов 1:05:14 Про принципы SOLID 1:06:29 (SRP) Принцип единственной ответственности 1:07:48 (OCP) Принцип открытости/закрытости 1:10:49 (LSP) Принцип подстановки Барбары Лисков 1:12:10 (ISP) Принцип разделения интерфейса 1:13:52 (DIP) Принцип инверсии зависимостей 1:20:16 Закон Деметры 1:23:48 Вопрос: О паттерне медиатор 1:26:21 Вопрос: О DI контейнерах и параметрическом полиморфизме 1:29:30 Вопрос: О принципе единственной ответственности

[@konstantinchvilyov9602]

identity [aɪˈdentɪtɪ] узнаваемость, своеобразие, тождественность, самобытность, самоопределение; опознание, тождество, отождествление, личность; опознавательный, личный, единичный.

[@konstantinchvilyov9602]

incapsulate [ɪnˈkæpsjʊlɪt] = encapsulate[ɪnˈkæpsjʊleɪt] - отсечь, изолировать, поместить[ в оболочку], герметизировать.

[@vladimirluchko3644]

Про DIP у того же Мартина хорошо рассказано. Он описывает его суть как "Суть не должна зависеть от деталей". То есть в чистой архитектуре в центре бизнес сущности и правила, а на переферии - интерфейсы с пользователем, бд, другими сстемами. И вот последнее - это детали, они могут меняться в процессе сопровождения продукта, а суть системы - её бизннс-правила не вызывают детали напрямую, то есть не зависят от них. А опеделяют интерфейсы, от которых наследуются детали. Тогда изменения в деталях не трогают сердце продукта.

[@konstantinchvilyov9602]

Цель: слабая связь и сильное единение.

[@konstantinchvilyov9602]

simulation [sɪmjʊˈleɪʃn] воспроизведение, образец, образ.

[@user-ji7mr8mw4o]

Виталий Чернышев, лайк

[@konstantinchvilyov9602]

composition [kɒmpəˈzɪʃn] соединение, сочинение, произведение, состав, строение

[@konstantinchvilyov9602]

interpretation [ɪntɜːprɪˈteɪʃn] - [ис]толкование, объяснение, разъяснение, прочтение, трактование, трактовка; устный перевод, перевод; устный.

[@konstantinchvilyov9602]

module [ˈmɒdjuːl] отсек, блок, независимая единица, нормированная часть, единица измерения

[@konstantinchvilyov9602]

Encapsulation [ɪnkæpsjʊˈleɪʃn] обволакивание, сокрытие, покрытие, отсечение, пакетирование, помещение[ в оболочку]; оболочка.

[@vladimirluchko3644]

У Роберта Мартина в "Чистой архитектуре" про SRP сказано, что данное у вас опсание некорректно. Верно будет: "Модуль должен отвечать за одно и только за одно заинтересованное лицо" или "Модуль должен иметь одну и только одну причину для изменения". То есть не про функционал модуля, а про источник для его изменений. Там ещё пример приводится, когда двум разным акторам сначала нужен был вроде бы одинаковый отчёт, но со временем они стали расходиться, и тогда изменения для одного стали задевать другого.

[@konstantinchvilyov9602]

element [ˈelɪmənt] составляющая, звено, часть, деталь

[@vladimirluchko3644]

Про бизннс правила интересный момент. Если они часто изменяются, как в вашем примере с банком и их продуктом, то вокруг чего должна выстраиваться архитектура? Вроде как бизнес-правила это по определению центральная сущность системы, а всё остальное желательно чтобы было более-менее легко заменяемо. Но если мы реализуем бизнес правила в виде плагинов, то что-то остаётся стабильным? Некоторый костяк системы, внутренние процессы? Что-то не имеющее отношение к бизнесу, а просто наша максимально гибкая архитектура?

[@konstantinchvilyov9602]

decomposition [diːkɒmpəˈzɪʃn] разложение

[@maximtimakov4135]

Ядро Linux написано в ООП-стиле, хотя и на Си

[@user-sq7hg2oc7q]

Молодец, умеешь чужие фразы повторять собачка

[@objectobj]

это Тесак что ли?

[@dimanroman4803]

Розенбаум

[@fesalam1592]

Нет.

[@java_couch]

Dependency inversion не имеет ни какого отношения к iOc контейнерам, это одна из самых часто делаемых ошибок джунов на собесе, Ioc контейнер это инверсия контроля и его частная реализация DI - dependency injection

[@konstantinchvilyov9602]

function [fʌŋkʃn] действовать, работать; назначение, действие, должность, приём. functionality [fʌŋkʃəˈnælɪtɪ] действенность, работоспособность, пригодность.

[@konstantinchvilyov9602]

mediator [ˈmiːdɪeɪtə] посредник, ходатай, примиритель

[@konstantinchvilyov9602]

coupling [ˈkʌplɪŋ] связь, соединение, стыковка, сцепление, спаривание. couple [kʌpl] пара, соединить, связать, соединять.

[@konstantinchvilyov9602]

minimum [ˈmɪnɪməm] наименьший

[@konstantinchvilyov9602]

capsule [ˈkæpsjuːl] коробочка, оболочка, отсек, облатка, ампула, капсюль, мембрана, капсула.

[@konstantinchvilyov9602]

minimization [mɪnɪmaɪˈzeɪʃn] сведение к наименьшему, уменьшение

[@konstantinchvilyov9602]

invariant [ɪnˈve(ə)rɪənt] неизменяемый, неизменный