Курс SOLID та Meta-принципи в ООП: Пишемо чистий та розширювальний код

Чого ви навчитеся

• Формулювати визначення принципів SOLID і метапринципів: DRY, KISS, YAGNI, SoC, CQS, закон Деметри, принцип найменшого подиву
• Розпізнавати «запахи» поганої архітектури: накопичення відповідальностей, надмірну зв’язаність, надто широкі інтерфейси, приховані залежності
• Рефакторити порушений код на C# за прийомами з курсу — від виділення інтерфейсу до поділу рівнів
• Застосовувати патерни, що підтримують принципи: фасад, адаптер, шаблонний метод, стратегію, відвідувача
• Впроваджувати залежності й збирати об’єкти вручну або через IoC-контейнер
• Обирати між ранніми та відкладеними абстракціями залежно від того, публічний це API чи приватний

Кому підійде курс

Курс не підійде тим, хто ще не писав код на C# чи іншій об’єктно-орієнтованій мові: матеріал стартує з проєктування, а не з основ мови.

Як проходить навчання

• Кожен принцип за однією схемою: визначення → порушення → рефакторинг — Одразу бачиш, як теорія перетворюється на правки коду, і можеш повторити шлях на своєму проєкті
• Порушення показані на кейсах із практики — Вчитися розпізнавати проблеми доводиться не на штучних прикладах, а в коді, схожому на робочий
• Живий код на C# замість переказу правил — Розбираєш теми, яких немає в загальних курсах зі SOLID: контракти, варіантність узагальнених типів, порушення підстановки в колекціях
• IoC-контейнер будується покроково на уроці — Розумієш, як контейнер працює всередині — від реєстрації відповідностей до рекурсивного розв’язання залежностей, а не лише як його підключити
• Окремий розділ про конфлікти принципів — Застосування SOLID перестає бути набором правил і стає усвідомленим вибором із розумінням ціни

Що знадобиться

• Комп’ютер із середовищем розробки для C#
• Базове знання синтаксису C# чи іншої об’єктно-орієнтованої мови
• Доступ до інтернету для перегляду відеоуроків

Чому самостійно зазвичай не виходить

Принципи SOLID виглядають просто в переказі, але у власному коді порушення непомітні: клас роками обростає відповідальностями, а switch-case у публічному API здається нешкідливим рішенням. Без практики важко відрізнити надлишкову складність від необхідної узагальненості — сліпе слідування правилам породжує інтерфейси з єдиною реалізацією та наслідування, що приносить жорсткість.

У курсі кожне порушення показано на реальному коді й усунуто рефакторингом: ти бачиш не лише правило, а й ціну його неправильного застосування — від зламаного інваріанта базового класу до неможливості покрити клас модульними тестами.

Що зміниться

Як улаштований шлях

1. Основи і SRP Вступ до SOLID, «запахи» коду і принцип єдиної відповідальності: визначення, демо порушення, рефакторинг, пов’язані патерни
2. OCP і LSP Відкритість-закритість: розширення без правок наявного коду. Підстановка Лісков: контракти, Square і Rectangle, варіантність узагальнених типів
3. ISP і DIP Поділ інтерфейсів на кейсах із терміналами і конфігурацією. Інверсія залежностей: техніки впровадження, архітектура з плагінами, побудова IoC-контейнера
4. Метапринципи і баланс DRY, KISS, YAGNI, SoC, CQS, закон Деметри і принцип найменшого подиву — і фінальне зведення: як принципи співвідносяться між собою і де проходить межа з архітектурою

Програма курсу

47 уроків · 7 модулів · 4 години 33 хвилини відео · Кожен розділ рухається за однією схемою: визначення, демонстрація порушення на живому коді, рефакторинг і пов’язані патерни.

• Єдина відповідальність: старт у SOLID 6 уроків

  Навіщо потрібні принципи SOLID і як керувати залежностями. Визначення SRP через осі змін, порушення на рівні класів і методів, патерн фасад і правило ізоляції модулів, що часто змінюються.

  • План розділу0:39

    Оглядовий урок-план розділу, присвяченого принципу єдиної відповідальності (SRP): вводиться тема й перелічується, що буде розібрано далі — суть принципу, рівні його застосування, приклади порушень і практичні орієнтири для власного коду. Окремо пояснюється, що дотримання SRP робить код зручнішим у супроводі та допомагає тримати структуру класів зрозумілою.

  • Знайомство з принципами SOLID9:59

    Урок пояснює, навіщо потрібні принципи SOLID: проєктування розглядається через вихідний код, а чистота коду оцінюється за основними запахами — ригідністю, крихкістю, нерухомістю, в’язкістю та надмірною складністю. Показано, що майже всі ці запахи походять від тісної зв’язаності модулів, а об’єктно-орієнтовані мови дають змогу інвертувати залежності через динамічну диспетчеризацію. SOLID описується як набір принципів керування залежностями, застосовних на будь-якій мові програмування.

  • Визначення SRP9:27

    Дається робоче визначення SRP: у класу має бути лише одна причина для зміни, а обов’язки зручно уявляти як осі зміни вимог і підраховувати через користувачів його API. Розбирається приклад класу з багатьма обов’язками — від роботи з банківським терміналом до збереження платежу в базу даних — і показано, до яких проблем призводить таке скупчення. Також розрізняються висока зв’язність усередині класу та низька зв’язаність між модулями.

  • Демонстрація порушення SRP3:44

    Практичний розбір класу PaymentModel із MVVM-застосунку для купівлі квитків на приміські поїзди: метод оплати квитка реалізує водночас два механізми оплати — карткою через платіжний шлюз і готівкою з прийманням грошей та видачею решти. На схемі залежностей клас виявляється центральною частиною, яка знає про весь проєкт, і це є порушенням принципу єдиної відповідальності. Виправлення — виділення способів оплати в окремі частини — показано далі.

  • Ще приклади порушення SRP4:15

    Розбір нових прикладів показує порушення SRP на рівні окремих методів: збирання статистичних даних разом із форматуванням рядків, змішування політики високого рівня з низькорівневою механікою під час роботи з COM-портами та глобальним станом. Названо типові ознаки таких порушень: змішування бізнес-логіки з представленням або шаром збереження даних, обслуговування класом різних рівнів і гігантські функції, цілком побудовані на switch-case та if.

  • Патерни, пов’язані з SRP5:40

    Урок розбирає патерн фасад: після застосування SRP система розпадається на безліч дрібних класів, і фасад обгортає їх, даючи клієнту простий API для розв’язання одного завдання — це не вважається порушенням SRP. На демонстрації інтернет-магазину фасад ховає за одним методом пошук покупця й товару, роботу з даними кредитної картки та виклик банківського шлюзу. Додатково розглядаються компоновник і декоратор — патерни, пов’язані з принципом єдиної відповідальності.

• Відкритість-закритість: розширюємо код без правок 5 уроків

  Два класичні визначення OCP, демонстрація порушення на switch-case, рефакторинг через інтерфейс, патерни шаблонний метод і стратегія, три підходи до дотримання принципу.

  • Визначення OCP11:17

    Теоретичний розгляд принципу відкритості-закритості: нова поведінка додається додаванням коду, а не правкою наявного. Розбираються поліморфізм і динамічна диспетчеризація, опора на інтерфейси та абстрактні класи замість конкретних реалізацій, а також ризики правок наявного коду для клієнтів API. Окремо розглядаються відмінності двох трактувань принципу та принцип єдиного вибору, який ізолює відповідальність за вибір реалізацій.

  • Демонстрація порушення OCP2:09

    Розгляд класичного порушення принципу на прикладі класу, що обирає налаштування пристрою через switch-case: кожен новий пристрій вимагає правок, хоча публічний API залишається незмінним. Показано, що виділення окремого методу проблему не вирішує, а небезпека — у розмноженні switch-case по різних модулях. Розгляд завершується порівнянням двох трактувань принципу та висновком, що вони багато в чому про різне.

  • Рефакторинг проблемного коду8:00

    Практичний рефакторинг: пошук пристрою абстрагується за інтерфейс, кожен пристрій реалізує його у власному класі, а клас-оркестратор делегує роботу через композицію. У результаті код стає закритим для модифікації та відкритим для розширення: новий тип додається новим класом без правки наявної кодової бази. Додатково порівнюються водоспадний підхід і agile як відповідь на непередбачуваність майбутнього.

  • Патерни, пов’язані з OCP12:00

    Розгляд поведінкових патернів, що допомагають дотримуватися принципу відкритості-закритості: шаблонний метод для алгоритмів з варіативною частиною та стратегія як сімейство взаємозамінних алгоритмів, які обираються під час виконання. Порівнюються інтерфейси та абстрактні класи — їхня гнучкість для клієнта й розробника, обмеження множинного успадкування та практичне правило вибору. Окремо розглядається патерн «відвідувач» для додавання операцій над стабільною ієрархією класів.

  • Запахи порушення OCP1:22

    Розглядається типова ознака порушення принципу — розмноження логічних гілок: код обростає операторами if-else та switch-case. Наводяться три підходи до дотримання OCP: послідовності обробників на делегатах (ланцюжок відповідальності), успадкування з шаблонним методом або відвідувачем і композиція зі стратегією. Показано, що композиція в більшості випадків є кращою за класичне успадкування.

• Підстановка Лісков: нащадки, що не ламають контракт 6 уроків

  Формулювання LSP через поведінку, яку бачить клієнт, контрактне програмування, класичний приклад Square і Rectangle, варіантність узагальнених типів через out та in і прийоми написання замінних нащадків.

  • Визначення LSP3:51

    Теоретичний урок формулює принцип підстановки Лісков: об’єкти підтипу мають заміщувати об’єкти базового типу без зміни бажаних властивостей програми, тобто заміна однієї реалізації іншою не має змінювати поведінку, яку бачить клієнт. Розглядається зв’язок принципу з наслідуванням і поліморфізмом, а в динамічно типізованих мовах — з качиною типізацією. Також показано два шляхи порушення взаємозамінності типів: через порушення контракту та через порушення коваріантності й контраваріантності.

  • Контракти8:53

    Урок розбирає контрактне програмування: різницю між контрактом та інтерфейсом, який задає лише сигнатури без семантики, і склад контракту методу — типи та значення даних, винятки, коди помилок, побічні ефекти, передумови, постумови й інваріанти. На прикладі двох моделей банківських терміналів показано, як посилення передумов і послаблення постумов у нащадків порушує принцип підстановки. Заторкнуто й платформну підтримку явного оголошення перед- і постумов у .NET.

  • Демо порушення LSP7:45

    Практичний розбір класичного прикладу Square і Rectangle: наслідування квадрата від прямокутника за схемою «is-a» ламає інваріант базового класу, і тип виявляється несумісним із ним. Показано, що спроба виправлення через перевірку типів у клієнті розв’язує проблему лише частково та порушує принцип відкритості-закритості, тобто порушення LSP може приховувати порушення OCP. Роз’яснюється, що класи лише представляють концепції реального світу і не зобов’язані відтворювати відносини між речами, які вони представляють.

  • Рефакторинг проблемного коду3:17

    Урок показує, як усунути зламаний API квадрата: поведінку обчислення площі узагальнюється через інтерфейс, і кожна фігура реалізує контракт власним алгоритмом, після чого клієнт фізично не здатен зіпсувати дані об’єкта. Попутно розбирається змішування даних і поведінки в окремому обчислювачі площ. Підсумком стає парадокс: гнучкість досягнута наслідуванням, яке водночас міцно пов’язує нащадка з предком.

  • Ще приклади порушення LSP8:18

    Урок знайомить із варіативністю узагальнених типів — коваріантністю та контраваріантністю через ключові слова out і in — і розбирає порушення принципу підстановки в масивах, стеці та колекції лише для читання. Показано, що небезпечне присвоювання контейнерів компілятор забороняє, а коваріантність масивів призводить до винятку вже в рантаймі, коли контракт спливає під час виконання. Друга ознака проблеми — надлишок даункастів, що видає знання клієнтом нутрощів ієрархії.

  • Запахи порушення LSP2:03

    Урок збирає типові ознаки порушеного принципу підстановки: раптовий виняток про непідтримувану операцію з тіла успадкованого методу («відмова від спадщини»), порожні реалізації та даункасти, що змушують клієнта розбиратися у внутрішньому устрої абстракції. Серед прийомів — принцип tell, don’t ask, за якого клієнт просто надсилає повідомлення об’єкту. Зазначено, що порушення підстановки нерідко є наслідком проблем з OCP чи ISP і зникає разом із першопричиною.

• Поділ інтерфейсів: вузький API замість товстого 5 уроків

  Дві демонстрації порушення ISP — банківські термінали і конфігурація з синглтоном — з рефакторингом кожної, а також «запахи» вироджених реалізацій і патерни фасад і адаптер.

  • Демонстрація порушення ISP7:16

    Розглядається реальний кейс: банківські термінали різних виробників підключаються через COM-сервери та описані спільним інтерфейсом IBankTerminal. Коли для вікна налаштувань інженерів до цього спільного інтерфейсу додаються операції перевірки та сканування картрідерів, один із терміналів, що працює як чорна скринька, змушений викидувати NotSupportedException. Передача такого об’єкта у ViewModel обіцяє клієнтові виняток — це ознака надто широкого інтерфейсу та порушення принципу розділення інтерфейсів.

  • Рефакторинг проблемного коду2:53

    Практичне продовження кейсу про банківські термінали: операції роботи з картрідерами вирізаються зі спільного інтерфейсу та переносяться в окремий вузький інтерфейс IReadersCommunicable. Реалізують його лише термінали, які справді вміють працювати зі зчитувачами, а ViewModel приймає цю залежність у конструкторі, тому передати непридатний об’єкт стає неможливо. У результаті клієнт бачить лише спеціалізований набір членів, а зв’язаність між методами, що розрізняються за змістом, знижується.

  • Демонстрація порушення ISP #26:13

    Друга демонстрація порушення ISP: клас звітів напряму залежить від конкретного класу конфігурації, оформленого синглтоном, через що модульне тестування можливе лише частково. Витягнення інтерфейсу IAppConfig і підміна залежності тестовим дубляром дозволяють протестувати генерацію звіту, однак дубляр змушено заповнює всі властивості інтерфейсу, включно з непотрібними звітам. Доводиться вибирати потрібне з довгого переліку членів, тому логічним продовженням стає розділення інтерфейсу.

  • Рефакторинг проблемного коду #21:57

    Рефакторинг за ISP: з товстого інтерфейсу конфігурації виділяється вузький IReportsConfig, що містить лише ті властивості, які потрібні для генерації звітів. AppConfig успадковується від нового інтерфейсу, зберігаючи колишню поведінку, а клас Report приймає в конструкторі лише його. Модульний тест переробляється під вузький інтерфейс: у тестовому дублярі залишаються лише справді потрібні значення, і код перевірки стає простим та зрозумілим.

  • Запахи коду, рішення та пов’язані патерни7:44

    Теоретичне завершення розділу: розглядаються типові запахи порушення ISP — вироджені реалізації з NotSupportedException і клієнтський код, що використовує лише малу частку API класу. Для випадків, коли товстий інтерфейс чужий і його код змінити не можна, показано патерни фасад та адаптер, а також явну реалізацію інтерфейсу. Окремо обговорюється, коли такий рефакторинг доречний і де розміщувати інтерфейс щодо його клієнта.

• Інверсія залежностей: тестований код і IoC-контейнер 12 уроків

  Зв’язаність і інтерфейс-шов, мінливі та стабільні залежності, інверсія керування і впровадження залежностей, три техніки впровадження, архітектура з плагінами і покрокова збірка власного IoC-контейнера.

  • Визначення DIP2:58

    Урок пояснює поняття зв’язаності та наводить формальне визначення принципу інверсії залежностей: модулі верхнього й нижнього рівнів не залежать одне від одного, а спираються на абстракції. Показано, що принцип застосовний на рівні вихідного коду та на рівні збірок, а аналогія з вилкою і розеткою ілюструє розв’язування через стандартний інтерфейс.

  • Залежності4:04

    Урок вводить поняття залежності та її типи: фреймворки, сторонні бібліотеки, зовнішні системи на кшталт файлової системи й бази даних, а також користувацькі типи платформи. На прикладі класичного триланкового застосунку показано, що прямі зв’язки між шарами створюють жорстку зв’язаність, а запровадження інтерфейсу-шва дає змогу спрямувати залежність у зворотний бік.

  • Волатильні та стабільні залежності2:26

    Урок вчить відрізняти мінливі залежності від стабільних: залежність вважається мінливою, якщо потребує налаштування середовища, ще не написана, встановлена не на всіх машинах розробників або поводиться недетерміновано. Абстрагувати потрібно саме мінливі залежності, щоб підмінювати їх тестовими дублерами в модульних тестах.

  • Визначення IoC і DI4:01

    Урок розмежовує інверсію управління, принцип інверсії залежностей і впровадження залежностей. Інверсія управління описує перехід контролю до сторони, яку викликають; найпростіша її форма — зворотні виклики; впровадження залежностей названо основним способом здійснення інверсії управління, хоча вона можлива й без нього.

  • Демо порушення DIP1:59

    Розбирається клас перевірки розбіжностей показів двох фізичних пристроїв, який напряму залежить від їхніх класів. Жорстка прив’язка до обладнання не дає змоги підмінити пристрої тестовими дублерами й написати модульний тест — це типове порушення принципу інверсії залежностей.

  • Рефакторинг проблемного коду9:15

    Показано рефакторинг класу з прихованими залежностями: винесення інтерфейсів створює шов між доменною логікою та зовнішніми пристроями. Порівнюються три техніки впровадження — через конструктор, властивість і метод — за впливом на інкапсуляцію, після чого код перевіряється модульним тестом із тестовими дублерами.

  • Техніки DI8:36

    Урок розбирає три техніки впровадження залежностей: конструктор захищає інваріанти об’єкта, властивості придатні для необов’язкових залежностей з реалізацією за замовчуванням, а впровадження через метод доречне, коли зв’язок потрібен одному методу. Для кожної техніки показано сильні сторони та пастки, зокрема вимоги фреймворків на кшталт ORM до публічного конструктора без параметрів.

  • Архітектура за застосування DI5:21

    Урок розкриває архітектурну роль інверсії залежностей: зв’язки інвертуються так, щоб усі вказували через межу системи в один бік. Доменна логіка стає ядром застосунку, база даних і інтерфейс користувача — замінними плагінами, а створення залежностей і час їхнього життя збираються в єдиній інфраструктурній точці.

  • Чистий DI та IoC-контейнери3:56

    Урок знайомить із двома способами збирання залежностей: ручним Pure DI, за якого весь ланцюжок створюється оператором new і передається явно, та IoC-контейнером. Контейнер розв’язує залежності рекурсивно за графом типів — від запитаного об’єкта через інтерфейси й реалізації до шлюзу бази даних, а потім збирає ланцюжок назад.

  • Побудова наївного IoC-контейнера5:51

    Практичний урок: поетапно реалізується найпростіший IoC-контейнер на словнику типів і рефлексії. Метод Register заносить пару «запитаний тип — тип реалізації», метод Resolve створює екземпляр, рекурсивно розв’язуючи параметри конструктора; за відсутності типу в словнику контейнер генерує виняток.

  • Демо реалістичного застосунку12:10

    Розбирається демонстраційний WPF-застосунок на MVVM, що керує списком студентів і підтримує CRUD-операції. Показано, як фреймворк з’єднує подання й моделі через прив’язування даних та шви, а IoC-контейнер бере на себе створення залежностей і їхній життєвий цикл; зміна зберігання даних зводиться до нової реалізації інтерфейсу.

  • Запахи порушення DIP1:59

    Урок систематизує типові запахи порушення DIP: клас сам створює і приховує залежності, недетерміновані залежності на кшталт поточного часу й випадкових чисел, а також статичні залежності у вигляді синглтонів. Спільний спосіб лікування — виокремити шар абстракції та використовувати адаптери з тестовими дублерами, відв’язавши проблемний клас від деталей реалізації.

• Метапринципи проєктування: DRY, KISS, YAGNI та інші 9 уроків

  Метапринципи, на яких стоять конкретні принципи: єдине уявлення знань, випадкова і необхідна складність, відмова від функціональності на майбутнє, поділ задач, команди і запити, закон Деметри, принцип найменшого подиву і принципи побудови API.

  • DRY — Don’t Repeat Yourself («не повторюйся»)12:31

    Урок розбирає принцип DRY: кожен фрагмент знання в системі має мати рівно одне втілення — від коду та схем баз даних до документації. Розглядаються типові порушення — магічні рядки та числа, повторювана логіка, розсипані if-else і switch — і прийоми рефакторингу проти них: іменовані константи, виділення методів та обгорток, заміна переліків успадковувачами базового класу. Окремо показано, що однаковість полів даних не робить класи схожими: схожість визначає поведінка, а успадкування даних порушує принцип підстановки Лісков.

  • KISS — Keep It Simple, Stupid («тримай простіше»)8:01

    Урок пояснює принцип KISS: просте рішення є кращим за складне, бо чим складніша система, тим вища ймовірність поломки. Вводиться відмінність необхідної складності, заданої предметною областю, і випадкової — наслідку обраних рішень, з якою якраз і працюють проєктування та оптимізація. Наводяться практичні правила: декомпозиція та зв’язок із принципами SOLID, перевага композиції над успадкуванням, відмова від випереджальної оптимізації, подрібнення методів і правило скаута.

  • YAGNI — You Ain’t Gonna Need It («це тобі не знадобиться»)12:05

    Урок присвячений принципу YAGNI — відмові від функціональності «на майбутнє»: точки розширення, написані в очікуванні майбутніх змін, нерідко ніколи не використовуються, але ускладнюють систему. Розглядаються ціни переінженерії, критерій, за якого код на майбутнє допустимий, якщо не збільшує складність, і перевірка кожної функції запитаннями — чи потрібна вона зараз і чи дорого додати її пізніше. Показано, що принцип спирається на безперервний рефакторинг, модульне тестування та безперервну інтеграцію.

  • SoC — Separation of Concerns (розділення відповідальностей)4:23

    Урок пояснює принцип SoC: різні задачі системи мають жити в різних модулях, які перевикористовуються, розробляються та оновлюються незалежно. Розглядаються типові шари корпоративного ПЗ — інтерфейс, бізнес-логіка, презентаційна логіка та база даних — і головна загроза розділенню, витік абстракцій, з прикладами протікань та їх виправленням. Показано відмінність від принципу єдиної відповідальності в рівні застосування та випадки, коли змішування шарів трактується як рідкісний виняток.

  • CQS (Command Query Separation) (розділення команд і запитів)2:08

    Урок розбирає принцип CQS: кожен метод має бути або командою, що змінює стан, або запитом, що повертає дані, але не поєднувати обидві ролі. На прикладі функції входу показано, як змішування логіки команди та запиту робить сигнатуру оманливою, а розділення на окремі функції — як імена та сигнатури починають чесно відображати призначення. Завдяки відсутності прихованих дій принцип відносять до правил побудови зрозумілих API.

  • Принцип Деметри6:33

    Урок розбирає принцип Деметри як окремий випадок слабкої зв’язаності: методу дозволено звертатися лише до «друзів» — власних методів, методів аргументів, створених всередині об’єктів і прямих полів. Практичне правило — одна крапка при зверненні: ланцюжки виду об’єкт.член.член.метод сигналізують про вторгнення в чужі деталі та тісну зв’язаність класів. На прикладі розносчика газет показано перерозподіл відповідальності, а також випадки, коли ланцюжки допустимі — для структур даних і fluent-інтерфейсів.

  • Принцип найменшого здивування3:00

    Урок пояснює принцип найменшого здивування: компонент має поводитися відповідно до очікувань користувачів API, а код має і створювати очікування, і відповідати їм. На прикладах показано приховані побічні ефекти та часову зв’язаність — з’єднання з базою даних, що відкривається в одному методі та закривається в іншому, — а також нелогічні методи на кшталт успадкованого add у стека чи NotSupportedException під час роботи з масивом через IList. Розбирається, як такі сюрпризи руйнують довіру коду, що викликає, і як їх уникати під час проєктування.

  • Інкапсуляція та приховування інформації5:55

    Урок розділяє два поняття: приховування інформації забороняє клієнтам доступ до внутрішніх деталей класу засобами мови — приватними змінними чи політикою експорту типів, — а інкапсуляція дозволяє використовувати компонент, не вивчаючи його реалізацію. Розбирається поганий API із типами, що повертаються, без ясного змісту, та його виправлення зі зрозумілими типами, включно з монадами Result і Maybe. Мета інкапсуляції — захистити інваріанти, зробивши недопустимі стани неможливими.

  • Загальні принципи побудови API14:03

    Урок вводить характеристики API — простоту, розширюваність і узгодженість — та принципи їх досягнення. Головне правило простоти: додавати члени можна, видаляти не можна, а сумнівну функціональність краще відкласти; простота вимірюється часом опанування та кількістю звернень по допомогу. Розбираються баланс між потужністю та простотою, розширюваність через принцип відкритості-закритості та зворотну сумісність, а також практика проєктування — від написання клієнтського коду та прототипу до конструкторів зі значеннями за замовчуванням і зрозумілих винятків.

• Баланс принципів: архітектура і дизайн ПЗ 4 уроки

  Конфлікти принципів і способи їх розв’язання: SOLID проти YAGNI, OCP проти YAGNI, SRP проти ISP — і відмінність архітектури і дизайну через визначення архітектури як згоди щодо значущих компонентів.

  • Баланс між SOLID і YAGNI3:59

    Урок про баланс між SOLID і YAGNI: виправлення проблем проєктування через SOLID зазвичай додає класи та функції, тому бездумне застосування веде до запаху надмірної складності. Розбирається теза про те, що розробники розв’язують конкретні проблеми загальними рішеннями, а нарощування узагальненості API веде до зв’язаності. Шлях балансу — почати з конкретної реалізації, відстежувати схожість в інших місцях і виділяти абстракцію за правилом трьох повторень; інтерфейс з єдиною реалізацією розглядається як сигнал можливого порушення принципу повторно використовуваної абстракції.

  • Вибір між OCP і YAGNI для API2:27

    Урок розбирає конфлікт між OCP і YAGNI на прикладі методу з switch-case: в одній трактовці принцип відкритості-закритості не порушено, в іншій рішенням стає абстрактний базовий клас з нащадками. Відповідь на конфлікт — «залежить від ситуації», і визначальним чинником виявляється тип інтерфейсу: для приватного API пріоритет віддається YAGNI з відкладанням абстракцій, у публічному API відкритість-закритість застосовується одразу, оскільки рефакторинг дизайну при критичних змінах дорого обходиться клієнтам.

  • SRP проти ISP1:39

    Урок розділяє принципи єдиної відповідальності та розділення інтерфейсів, розібравши оману, ніби другий принцип існує лише для усунення порушень першого. SRP вимагає, щоб у класу була рівно одна причина для зміни, ISP — щоб клієнти не залежали від того, чим не користуються; обидва принципи виявляються різними поглядами на одну ідею, очима розробника та з позиції клієнта. На прикладі сховища даних з інтерфейсами IReader і IWriter видно, що обидва принципи застосовні до одного класу без суперечності.

  • Різниця між архітектурою та дизайном ПЗ5:15

    Урок розводить поняття архітектури та дизайну ПЗ. Архітектура — це домовленість досвідчених розробників про значущі компоненти системи: єдиного вищого рівня абстракції не існує, оскільки користувачі, розробники та власники бачать систему по-різному; вибір СУБД і UI-технології — просто інструменти, ізольовані інтерфейсами на межі, і такі рішення радять максимально відкладати. Дизайн зосереджений на рівні модулів, класів та їхніх обов’язків: архітектурні патерни включають клієнт-серверну структуру та SOA, а шаблони проєктування поділяються на поведінкові, структурні та породжувальні.

Часті запитання

Про цей курс

• Якою мовою написані приклади коду?

  Усі приклади і рефакторинги — на C#. Частина тем специфічна для платформи: варіантність узагальнених типів через out та in, порушення підстановки в масивах і колекціях, лондонська і детройтська школи мокування.

• Що потрібно знати до старту курсу?

  Синтаксис C# і базовий досвід об’єктно-орієнтованого програмування. Курс починається з проєктування, а не з основ мови.

• Чи знадобиться готовий DI-фреймворк?

  Ні. IoC-контейнер будується покроково на уроці — від реєстрації відповідностей до рекурсивного розв’язання залежностей, потім показаний у демо-застосунку на WPF і MVVM.

• Як улаштовані заняття з кожного принципу?

  За однією схемою: визначення, демонстрація порушення на реальному коді, рефакторинг проблемного коду, розбір пов’язаних патернів і «запахів», підсумкове повторення наприкінці розділу.

• Курс підійде, якщо я знаю SOLID лише за статтями?

  Так. Окремі уроки присвячені типовим ознакам порушень і конфліктам принципів між собою — від вибору між OCP і YAGNI для приватного і публічного API до правила трьох при виділенні абстракцій.

• Які патерни розбираються в курсі?

  Фасад, адаптер, композит, декоратор, шаблонний метод, стратегія і відвідувач — кожен у зв’язці з принципом, який він підтримує.

Доступ і матеріали

• Коли і як я отримаю доступ до курсу?

  Одразу після оплати, тієї ж секунди й автоматично. Чекати на підтвердження не потрібно. Доступ надходить двома шляхами водночас. Перший: на пошту, вказану при оформленні замовлення, приходить лист із посиланням на матеріали. Другий: те саме посилання з’являється у вашому акаунті на сайті, у розділі «Завантаження», і залишається там назавжди.

• Де зберігаються матеріали курсу?

  Усі відео та додаткові файли лежать у хмарному сховищі. Посилання на нього — у вашому акаунті на сайті, розділ «Завантаження», і в листі, який надійшов після оплати. Акаунт тут не формальність, а спосіб доставки: курс залишається в ньому назавжди. Навіть якщо лист загубився або ви згадали про купівлю через рік, посилання буде на місці.

• Чи можна завантажити матеріали, чи тільки дивитися онлайн?

  Завантажувати можна і варто. Радимо зберегти відео на комп’ютер і дивитися звідти. Причина проста: хмарне сховище не розраховане на перегляд відео. Іноді воно дозволяє увімкнути ролик просто у браузері, але якість при цьому помітно гірша за вихідну. На своєму комп’ютері ви побачите курс таким, яким його записували.

• Як довго діє доступ?

  Безстроково. Курс залишається вашим назавжди, повертатися до нього можна скільки завгодно разів. Якщо через рік чи два посилання раптом перестане відкриватися з технічних причин — напишіть на info@siluette.com.ua, ми його відновимо.

• Лист із доступом не надійшов — що робити?

  Насамперед: доступ у вас є в будь-якому разі. Увійдіть на сайт і відкрийте розділ «Завантаження» — посилання на курс уже там, незалежно від того, дійшов лист чи ні. Найчастіше лист губиться через одруківку в адресі під час оформлення замовлення. Ще варто заглянути до теки «Спам». Не виходить розібратися — не витрачайте час: напишіть на info@siluette.com.ua або в чат у правому нижньому куті сайту, ми допоможемо.

• На яких пристроях дивитися курс?

  Найкраще на комп’ютері або ноутбуці: завантажте відео й відкрийте будь-яким звичним плеєром. Знадобляться встановлені відеокодеки — на більшості комп’ютерів вони вже є. Завантажити курс можна на скільки завгодно пристроїв. А от телефон ми не радимо, і з двох причин. На маленькому екрані погано видно деталі, особливо якщо в уроці показують інтерфейс програми. І на телефонах часто немає кодеків для форматів, у яких записані відео.

Оплата та повернення

• Якими способами можна оплатити?

  Банківською карткою Visa, MasterCard або «Простір», через Google Pay, Apple Pay, Masterpass, Visa Checkout, платіжний QR-код, Botpay у Telegram чи Privat24. Є й оплата частинами: Монобанк (3 або 4 платежі), А-Банк (2, 3 або 4 платежі та розстрочка), Банк Глобус (8 платежів), «Скибочка» від OTP Bank (3 платежі), миттєва розстрочка та оплата частинами від ПриватБанку.

• Чи приймається картка, випущена не в Україні?

  Так. Платіжна система приймає картки з Євросоюзу та будь-яких інших країн. Одна деталь, про яку часто забувають: банк може попросити підтвердити платіж — у мобільному застосунку або кодом із СМС. Якщо оплата не проходить, перевірте застосунок банку та повідомлення.

• Як працює знижка 20% при купівлі кількох курсів?

  Додайте до кошика два курси або більше — знижка застосується автоматично до всіх товарів у кошику. Два курси: мінус 20% на обидва. П’ять курсів: мінус 20% на всі п’ять. Знижка поєднується з будь-якими акційними цінами й діє на весь каталог без винятків.

• Чи можна повернути курс або гроші?

  Цифрові товари поверненню та обміну не підлягають. Це загальне правило для всіх електронних товарів в Україні — постанова Кабінету Міністрів № 172 від 19 березня 1994 року. При цьому ми завжди на зв’язку. Якщо доступ не відкривається, посилання перестало працювати або файли пошкоджені — напишіть на info@siluette.com.ua, вкажіть дату та номер замовлення. Відновимо. Якщо щось незрозуміло в самому курсі, теж пишіть — підкажемо.

• Чи можна оплатити від організації за рахунком?

  Поки що ні. Ми працюємо лише з приватними покупцями — безготівкової оплати за рахунком від юридичних осіб зараз немає.

Як проходить навчання

• Чи є зворотний зв’язок із викладачем і перевірка завдань?

  Ні. Усі курси — це записи уроків для самостійного вивчення: викладач не відповідає на запитання і не перевіряє домашні завдання. Саме тому курси коштують значно дешевше за навчання з куратором. Ви отримуєте той самий матеріал, але займаєтеся самі та у своєму темпі.

• Чи видається сертифікат?

  Так, цифровий сертифікат — на запит і безкоштовно. Напишіть на info@siluette.com.ua, вкажіть ім’я та прізвище саме в тому вигляді, в якому хочете бачити їх у сертифікаті, і ми надішлемо його протягом доби.

• Чи потрібен досвід, щоб почати?

  Для більшості курсів — ні. Вони розраховані на початковий рівень і пояснюють з азів. Якщо курс потребує підготовки, це сказано в його описі.

• Чи є терміни проходження курсу?

  Ні. Ані дедлайнів, ані розкладу, ані доступу, що згорає. Завантажили — дивіться коли зручно, з будь-якими перервами.

• Чи можна поділитися курсом з іншою людиною?

  Курс купується для особистого використання, і ми просимо ставитися до цього по-людськи: за кожним уроком стоїть робота, а ціна й так суттєво знижена.

Підтримка

• Куди писати, якщо щось не працює?

  Найкраще на info@siluette.com.ua. Є й чат у правому нижньому куті сайту, але пошта надійніша: там можна все описати докладно та додати знімки екрана. Прохання: опишіть, що саме ви робили і що пішло не так, та додайте знімок екрана з помилкою. Так ми вирішимо питання одразу, а не з’ясовуватимемо півдня, що сталося.

• Як швидко відповідає підтримка?

  У робочий час, з 9:00 до 19:00, на пошту зазвичай відповідаємо протягом години, у чаті — за кілька хвилин. Після 19:00 теж буває, але час відповіді не обіцяємо.