Мета та підготовка
Створити модель предметної області з явною ідентичністю та перевіреним початковим станом. Потрібно знати клас, конструктор, властивість і виняток. Встановіть підтримуваний .NET SDK із C#12 або новішим. Перевірте dotnet --info. Створіть проєкт командою dotnet new console -n DomainLab, перейдіть у папку й відкрийте Program.cs у редакторі.
Теоретичний мінімум
Сутність розрізняють за ID попри зміну інших властивостей. Guid є типом значення для такого ідентифікатора, але не замінює авторизацію. Властивість get-only дозволяє читати стан без довільного запису. List зберігає посилання на об’єкти; копія списку не створює незалежні сутності. Інваріант демонстрації: непорожні ID і назва та додатна місткість.
Повний демонстраційний код
Замініть Program.cs наведеним прикладом. Top-level інструкції повинні передувати оголошенням типів.
using System;
using System.Collections.Generic;
using System.Linq;
var rooms = new List<Room> {
new(Guid.NewGuid(), "Лабораторія A", 12),
new(Guid.NewGuid(), "Лабораторія B", 24)
};
var suitable = rooms.Where(room => room.Capacity >= 20).ToList();
if (suitable.Count != 1 || suitable[0].Name != "Лабораторія B")
throw new Exception("Порушено очікування відбору");
foreach (var room in suitable)
Console.WriteLine($"{room.Name}: {room.Capacity}");
public sealed class Room
{
public Guid Id { get; }
public string Name { get; }
public int Capacity { get; }
public Room(Guid id, string name, int capacity)
{
if (id == Guid.Empty) throw new ArgumentException("ID");
if (string.IsNullOrWhiteSpace(name)) throw new ArgumentException("Name");
if (capacity <= 0) throw new ArgumentOutOfRangeException(nameof(capacity));
Id = id;
Name = name.Trim();
Capacity = capacity;
}
}
Запустіть dotnet run. Очікується «Лабораторія B: 24». new(...) виводить тип Room із контексту колекції. Where приймає lambda з логічною умовою, ToList матеріалізує відбір. Перевірка Count захищає очікування кількості, а перевірка назви — конкретний результат. Це прості виконувані перевірки; у більших проєктах їх можна перенести у тестовий framework.
Покрокове виконання
Спершу складіть словник «аудиторія», «місткість», «ідентифікатор». Визначте, яку одиницю місткості використовуєте. Побудуйте дві Room вручну й перевірте, що ID різні. Додайте третю аудиторію рівно на 20 місць і оновіть очікування відбору. Для порожнього списку результат має бути порожнім без помилки.
Перевірте конструктор із Guid.Empty, пробілами в назві й нульовою місткістю через try/catch. Не вилучайте перевірки лише для проходження некоректних даних. Намалюйте класову модель з властивостями й поясніть відповідність кожного елемента кодові. Назви на схемі та в реалізації повинні виражати ті самі поняття.
Самостійне завдання
Спроєктуйте сутності Equipment і Reservation для вашої лабораторії. Визначте ID, потрібні значення та зв’язок бронювання з конкретним пристроєм. Додайте щонайменше два інваріанти й три приклади відхилення. Реалізуйте колекцію та запит, який відповідає реальному питанню, наприклад вибір обладнання за категорією й станом.
Створіть власний набір із п’яти вигаданих сутностей. Поясніть унікальність ID і значення однакових назв. Основну модель потрібно розробити самостійно; демонстрація Room показує конструктор і відбір. Додатковий варіант: Dictionary<Guid,Equipment> із політикою дублікатів та пошуком через TryGetValue.
Типові помилки й налагодження
Unresolved symbol часто означає пропущений using або неправильну назву. Помилка top-level statements виникає через розміщення інструкцій після класів. Однаковий Guid, скопійований для кількох сутностей, руйнує ідентичність. Якщо Where повертає неочікуваний набір, перевірте оператор на границі та момент матеріалізації.
Результат і контрольні питання
Подайте проєкт без bin/obj, словник, модель і результати перевірок. Поясніть get-only властивість, Guid і тип параметра lambda. Чому однакові назви не означають одну сутність? Що саме копіюється при створенні нового List з класовими елементами? Як гарантуєте коректний стан одразу після конструктора?
Читання Program.cs та контроль моделі
У шаблоні з top-level statements команди виконання розташовуються перед оголошеннями типів у цьому файлі. Клас Room описує власну структуру, а створення його екземплярів виконується командами вище. Якщо перенести top-level код після класу, компілятор повідомить про порушення структури файла; поверніть порядок згідно з демонстрацією.
Для кожного поля запишіть тип і предметне значення. Guid розрізняє аудиторії, string зберігає назву, int — цілу місткість. Дві кімнати з однаковою назвою можуть бути різними об’єктами. У власному завданні поясніть, чи ім’я потребує унікальності, та де це правило перевірятиметься.
Перевірте фільтр на порожній колекції, одній кімнаті та кількох зі значенням рівно на межі. Для Where(r => r.Capacity >= required) рівність проходить умову. Якщо потрібна інша семантика резерву місць, змініть контракт до написання перевірки. Збережіть очікувані id результатів, бо однакові назви не дозволяють надійно звірити об’єкти.
У звіті покажіть, що змінюється після ToList: нова колекція містить вибрані посилання, а її додавання чи видалення елемента не змінює структуру початкового списку. Це не обіцяє незалежності внутрішнього стану кожного Room. Поясніть цю межу на власному прикладі та не розкривайте setter без необхідності для предметних дій.
Окремий контрольний сценарій
Додайте у власну таблицю перевірку неправильного required: нуль або від’ємне число. Визначте, чи це допустимий запит «усі аудиторії» або помилка контракту. Обидві політики потребують явного пояснення, тому не залишайте їх випадковим наслідком умови LINQ. Після вибору запишіть відповідний тест і поведінку користувацького повідомлення. Структура типів допомагає виконати запит, а предметне правило задає його допустимий зміст.
Схема процесу
Погоджуємо предметні поняття.
Самоперевірка
Як обґрунтувати відповідь своїми словами?
Підсумок
Предметна модель має узгоджені назви, ідентичність і перевірки початкового стану. LINQ відбір пов’язує код із конкретним питанням. Незалежність колекції та сутностей потрібно розрізняти.