Первое условие проверяет, что массив начинается на 1, 2, заканчивается 10, и содержит что угодно посередине (..). Это особенно полезно при валидации данных, когда важна структура последовательности, но не все элементы. Списковые паттерны упрощают такие проверки, делая код более декларативным и понятным.

Второе — определяет, что точка находится в первой четверти, если обе координаты больше нуля. Такой подход позволяет сопоставлять элементы кортежей напрямую в условиях, избегая промежуточных переменных. Это делает логику более компактной и выразительной, особенно при работе с координатами, диапазонами или другими структурированными данными.

Списковые паттерны также поддерживают вложенные проверки, сопоставление с отбросом (_), и комбинацию с другими паттернами C#. Они интегрируются с switch-выражениями и pattern matching, предоставляя единообразный способ работы с различными структурами данных. Это существенно сокращает количество boilerplate-кода и улучшает читаемость при работе с массивами, списками, кортежами и другими индексируемыми коллекциями.

Ещё больше полезного контента в телеграмм канале EasyProger - https://t.me/easyprogers

Мнемоника для тупых: "Мадам-шлюха и её девки"

Представь бордель. В нём есть:

Мадам-мразь (она же абстрактный класс):

— Сама не трахает клиентов (нельзя new Мадам() — только трясёт кокосами и кричит: "Вы что, охуели? Я же мадам, а не шлюха!").

— Говорит правила: "Все девки должны уметь 'трахать по-итальянски' и 'делать массаж с перцем'!" (это ваши абстрактные методы).

— Если не научишься — вылетишь (иначе класс-наследник будет абстрактным, а это путь в никуда, бро).

Девки-проститутки (ваши наследники):

— Обязаны выполнять правила мадам (реализовывать абстрактные методы).

— Могут добавить своё (например, "трах с вибратором — +500 к баблу").

— Если не сделают — вылетят на мороз (ошибка компиляции: "Ты не девка, ты лузер!").

Пример кода, чтобы мозг не взорвало

// Это МАДАМ. Она не шлюха, а УЧИТЕЛЬНИЦА ПОХАБНЫХ НАУК.

abstract class Мадам {

public abstract void ТрахнутьПоItaliani(); // Абстрактный метод — без реализации!

public virtual void ДатьНапиток() {

Console.WriteLine("Виски с цианидом — бесплатно");

} // Виртуальный метод — можно переопределить, но не обязательно.

}

// Это ДЕВКА-ЛУЗЕРКА, которая не выучила урок.

class Ленчик : Мадам {

public override void ТрахнутьПоItaliani() {

Console.WriteLine("Ленчик трахает как сдохшая рыба... Мадам в ярости!");

}

// Забыла про ДатьНапиток()? Не страшно — виртуальный метод можно не трогать.

}

// Это ДЕВКА-ПРОФИ, которая знает своё дело.

class Катя_С_Тату : Мадам {

public override void ТрахнутьПоItaliani() {

Console.WriteLine("Катя в деле — клиенты плачут от счастья!");

}

public override void ДатьНапиток() {

Console.WriteLine("Катя даёт текилу... и сразу к делу!");

}

}

Почему это работает?

— Мадам = abstract class — без неё бордель (программа) рухнет.

— Девки = наследники — без них мадам просто тряпка с криками.

— Правила = абстрактные методы — если не выполнить, получишь баттхерт от компилятора.

Каждый раз, когда забудешь про abstract, вспоминай:

"Мадам не трахается сама, но заставляет всех трахаться правильно!" 💦

Вывод

Теперь ты никогда не спутаешь абстрактный класс с обычным. Помни:

— Нет new — нет проблем (и никаких шлюх в одиночку).

— Правила есть правила (абстрактные методы обязаны реализовать).

— Если не научишься — вылетишь (как Ленчик после первой же смены).

P.S. Если коллега спросит, как запомнить ООП — шли его сюда. Пусть тоже посмеётся... или заревнует. 😈

Ставь лайки, если теперь C# для тебя — как бордель, а не кошмар экзамена. И да пребудет с тобой... override!

Удачного собеседования, малята.

- Контравариантность (in) — когда ты можешь подсунуть более общий тип вместо конкретного.

- Инвариантность — когда никакой хуйни не будет, только строгий тип.

Звучит как магия? Нет, братан, это проституция в ООП.

Шлюха №1: Ковариантность (out)

Фишка: «Вышла с олигархом — считай, что с мужиком».

Представь:

- У тебя есть шлюха, которая работает только с олигархами (Derived).

- Но ты её записываешь в список «работает с мужиками» (Base).

- Почему можно? Потому что олигарх — это мужик, а не наоборот!

Код для тупых:

class Мужик {}

class Олигарх : Мужик {} // Наследуется, да

IEnumerable<Олигарх- олигархи = new List<Олигарх>();

IEnumerable<Мужик- мужики = олигархи; // Работает! Ковариантность (`out`)

- IEnumerable<T> — ковариантен благодаря out T. Ты выпускаешь (out) олигархов как мужиков.

Мнемоника:

- «Out — шлюха выебала олигарха, считай, что мужика!

- Если вышла с Rolls-Royce — значит, с машиной вышла».

Шлюха №2: Контравариантность (in)

Фишка: «Ебёт мужика — считай, что олигарха».

Теперь:

- У тебя есть шлюха, которая работает со всеми мужиками (Base).

- Ты её нанимаешь для олигархов (Derived).

- Почему можно? Потому что мужик может оказаться олигархом (а не наоборот)!

Код для тупых:

Action<Мужик- обработатьМужика = (m) =- Console.WriteLine("Ебашим мужика");

Action<Олигарх- обработатьОлигарха = обработатьМужика; // Работает! Контравариантность (`in`)

- Action<T> — контравариантен благодаря in T. Ты принимаешь (in) мужиков как олигархов.

Мнемоника:

- «In — шлюха ебёт мужика, считай, что олигарха!

- Если взяла любого в подъезде — может, это Ротенберг».

Шлюха №3: Инвариантность (никакой in/out)

Фишка: «Ты — олигарх? Нет? Тогда вали нахуй!».

А теперь представь самую принципиальную шлюху:

- Она работает ТОЛЬКО с олигархами (Derived).

- Если ты предложишь ей просто мужика (Base) — она скажет: «Ты шо, еблан? У меня контракт только с Ротенбергом!».

- И даже если олигарх придёт — она не согласится считать его «просто мужиком».

Код для тупых:

List<Олигарх- олигархи = new List<Олигарх>();

List<Мужик- мужики = олигархи; // ОШИБКА! Инвариантность.

- List<T> — инвариантен. Нету in/out - никаких преобразований. Тип жёстко фиксирован, как принципы шлюхи после 30.

Мнемоника:

- «Инвариантность — шлюха не ебёт никого, кроме олигархов.

- Ни мужиков, ни бомжей — только паспорт Ротенберга!»

Как не облажаться?

- out = выходи с олигархом, но считай его мужиком - сужение типа (Derived - Base).

- in = входи к мужику, но считай его олигархом - расширение типа (Base - Derived).

- Без in/out = только как в контракте - никаких хитростей (инвариантность).

Лайфхак:

Каждый раз, когда пишешь List<T> или Dictionary<TKey, TValue>, вспоминай:

- «Если шлюха не ставит галочку «подходит для всех мужчин» в профиле — значит, она инвариантна. Ищи другую».

Почему это гениально?

Потому что:

1. Эмоции = память. Ты не забудешь про шлюх, даже если забудешь синтаксис C#.

2. Юмор снимает стресс. Теперь компилятор будет кричать «invariant», а ты улыбнёшься и поправишь код.

3. Ты станешь легендой в команде. «Братан, а как ты запомнил контравариантность?» — «Да шлюхами, чё».

P.S.

Если после этого ты всё равно запутаешься — значит, ты слишком трезвый. Или не смотрел «Горько!».

А если запомнил — ставь лайк, комментируй «Спасибо, теперь шлюхи в моём коде», и не забудь: в C# всё решают контракты... и проститутки. ??

P.P.S. Инвариантность — это когда шлюха сказала: «Ты не Ротенберг? Тогда даже не звони». А ковариантность/контравариантность — это когда она согласна на компромисс. Выбирай, какая тебе ближе.

P.P.P.S. Автор не несёт ответственности за ваши мысли о ковариантности на свиданиях. Но если помогло — пиши в личку, устроим контравариантный квест. ??