Мария Мальцева

Я больше скажу, даже не джуниор постоянно подглядывает. Чтение документации - 60% времени работы любого разработчика

Называется embedded.

При этом направления могут быть разные, совсем не факт, что придется разбираться в электронике и механике.

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

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

*((int *) 0) = 1;
Ни в одном другом языке это не осуществляется так просто.

1. Создание технического задания - какие фичи есть и как они работают.
2. Создание частного технического задания - подробное описание каждой фичи, особенности, поведения и прочего (кнопки, меню, апи вызовы и прочее).
3. Разработка архитектуры проекта под требования и ограничения ТЗ.
4. Проработка архитектуры на более низком уровне - модули, подсистемы и прочее.
5. Проектирование пользовательского интерфейса и его дизайн прочее.
А далее уже более детальная разработка частей/модулей проекта и написание кода - независимые части/модули можно делать параллельно. От проекта к проекту детали могут меняться - но в целом логика примерно такая.

Синтаксис общий в той мере, что аккуратно написаный код на C будет компилироваться на всех популярных компиляторах C/C++.
Этот курс гораздо лучше, чем ничего, а то, что ты приобретешь некоторые познания в C++, тебя не испортит.

Вообще, это правильный подход к диаграммам. )
Вот что писал Боб Мартин:
"Возьмите за правило выбрасывать ненужные UML-диаграммы. А еще
лучше, не создавайте их на постоянном носителе. Рисуйте на доске или
на клочках бумаги. Почаще стирайте с доски и выбрасывайте эти об-
рывки. Не привыкайте к инструментарию CASE или к графическим ре-
дакторам. Для таких инструментов есть свое время и место, но жизнь
большинства UML-диаграмм недолговечна."
Хотя, далее, некоторые полезно и сохранять. Общий дизайн системы (идея) или те моменты которые из текста программы будет сложно понять.

Упрощенно можно так подходить к выделению классов и интерфейсов.
Есть два реальных объекта. Они относятся к разным классам. Со своими особенностями. Но у них есть некие одинаковые свойства. Например шаблоны функций. пример в общем случае быстрая сортировка это шаблон реализующий алгоритм, но этот шаблон не знает как реально сравнивать объекты. То есть это абстрактный класс объединяющий конкретные быстрые сортировки конкретных объектов. Можно сказать, что абстрактный класс это вынос общих методов и полей их своих потомков. При том что реально мы никогда не создадим экземпляр этого класса.
Выделение интерфейса. Обычно применяется для разделения систем на отдельные на зависимые части. Например кнопка включает лампу. В программе это реализуется так
кнопка имеет поле лампа. т.е. реализация кнопки зависит от лампы. Если тип (или код) лампы поменялся, то и часть кода ответственная за кнопку тоже меняется. По крайней мере должна протестироваться. Но можно договориться разделить все устройства которые могут что-то включать (кнопки) и могут быть включены (лампы, двигатели, телевизоры...) и указать как им взаимодействовать.
Т.е. примерно так:
Кнопка управляет устройствами.
Устройство должно иметь метод "включить".
Лампы, телевизоры, двигатели должны реализовать это метод у себя.
Итого одна и та же кнопка (без изменения кода) управляет целой группой разнородный устройств (но реализующих общие правила взаимодействия)

По картинкам:
у нас есть объекты
связь 0, связь 1, ...связь 3
так же объект шина из связей.
общее для них это они все имеют имя.
также они имеют некоторые правила передачи сигналов.
Это дает нам два класса Net и Bus. Кроме того Bus включает в себя много Net.
Далее хотелось бы , что бы эти классы были независимы от правил. т.е что бы правила мы могли назначать сами. возможно динамически. Поэтому net и bus имеют метод назначающий правила rule (с общим интерфейсом) (которые можно менять, и не менять реализацию net, bus ).
Итого Выделили общие свойства из net, bus в абстрактный класс AbstractNet. bus включает много net. Вынесли правила (которые будут часто меняться и которые мы возможно еще не знаем) за общий интерфейс.
примерно так. упрощенно.

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

Правило хорошего тона: API класса должен быть доступен только через методы или properties (что, по сути - синтаксический сахар над методами), а поля должны быть только private/protected.