netology-code / aios-homeworks

Домашние задания по курсу «Swift: объектно-ориентированное программирование»

Блок 1. ООП

1.1. Основы ООП.

1.2. Классы, структуры и перечисления.

1.3. Интерфейсы и конструирование собственных типов.

Блок 2. Типы объектов. Взаимодействие объектов.

2.1. Классы и структуры: Value Type и Reference Type.

2.2. Продвинутые свойства объектов.

2.3. Замыкания и функциональное программирование.

Блок 3. Протоколы, наследование, переопределение

3.1. ООП: наследование, переопределение методов, инициализация классов.

3.2. Протоколы: создание моделей с полиморфным поведением.

3.3. Ошибки и возможности: моделирование исключительных ситуаций и работа с ошибками.

aios-homeworks's Issues

ДЗ - 3.2 - Обратная связь по заданию - что можно было бы улучшить.

Домашнее задание к занятию 3.2. Протоколы и расширения

Часть 1.

Конфигурация параметров машины в задании не позволяют создать полностью уникальную машину.
На склад и шоу рум случайно (даже рандомом при создании) может попасть несколько машин с одинаковыми параметрами.
Поэтому хорошо бы добавить в ТЗ, как в реальной жизни поле уникального идентификатора автомобиля. С ним и работать удобней. И ближе к реальности.

Часть 2.

2. Добавьте свойства:
cars' (массив, чтение и запись): хранит список всех машин в наличии.
Три массива с машинами - далеко от реальной жизни. В реальности одна база и поле, где машина находится.
Для тренировки три массива - ОК. Но тогда измените в ТЗ, что массив cars - должен быть "вычисляемым" из двух других и иметь признак {Get}. Но самое главное, пожалуйста, в задании, в презентациях, на вэбинарах - особо уделите этому внимание. Т.к. из текущих материалов, да и ряда внешних источников - это не совсем на поверхности.
Плюс ряд Экспертов предлагают это сделать в комментариях на доработку, хотя этого нет формально в ТЗ.
3. Добавьте методы:
**'offerAccesories( :)': принимает массив акксесуаров в качестве параметра. Метод предлагает клиенту купить доп. оборудование.**_
Абсолютно бесполезный метод. Просто в эфир предлагаем что-то купить. Далее в проекте не применим.
Правильнее было, чтобы метод принимал массив аксессуаров и машину. Предлагал купить и добавлял аксессуар к машине. Тогда метод можно использовать далее.

Часть 4.

2. Добавьте методы:
'addEmergencyPack()': не принимает никаких параметров. Метод добавляет аптечку и огнетушитель к доп. оборудованию машины.
Данная формулировка вводит в ступор. Непонятно, что требуется от метода. Т.к. если метод не принимает машину, то он может добавить что-то только в какую-то внешнюю переменную. Т.е. самое простое это какой-то массив на все машины этого массива. И это вызывает недопонимание. И опять таки мы не можем метод использовать дальше и вынуждены создавать новый адресный метод или дублировать код в других методах.
Поэтому целесообразно было бы в ТЗ указать, что метод принимает машину.