На этом уроке мы перенесём проверку аргументов командной строки в отдельную функцию. Попутно исправим некоторые недочёты и ошибки.
Обоснуйте своими словами, почему мы решили не создавать отдельный класс для проверки аргументов?
Дата отправки отчёта:
6 декабря 2016 г.
Задание выполнено: за
20 мин.
Чему научился:
Повторил пройденное
Что было сложным:
найти время
Комментарии:
Всё же проверять вначале на предмет отсутствия параметров следует, не стоит обобщать проблемы, я придерживаюсь всегда к точки зрения: "Конечного пользователя надо тыкать носом, чтобы он понял где его ошибка, а не посылать курить мануалы (выдавать описание) из-за, возможно, банальной проблемы, можно же указать конкретно и ниже выдать мануал." По поводу распарсивания списка подарков, реализовал ещё на прошлом уроке, на этом уроке переделал под StringBuilder. По поводу того, что не нужно для парсинга аргументов создавать доп класс, ну как минимум потому, что эти аргументы приходят в основной класс программы, для их обработки достаточно добавить метод/функцию, так как в нашем случае это не что-то сложное, всё что было сложным (FruitReader*) уже вынесли в отдельные Классы.
Научился: Парсинг аргументов выделять в отдельную функцию. И нашла такую интересную функцию как String.startsWith.
И еще маленькую ошибку нашла.
Создала GiftsReaderString(s), записала что сумка принимает машинки, а потом пересоздала GiftsReader и получилось, что сумка стала фрукты опять принимать. Ну и пришлось мне еще пару часов выделить на улучшение кода. Теперь я могу доложить предметы копированием из одной сумки в другую. Потом пробежалась по коду и добавила немного логов: close() вполне себе override, все отлично. А вот когда gre сумку успел создать Трудности: Заменить join на цикл for рука не поднялась. Наверно потому, что маленькому контроллеру между внешним источником данных и внутренним удобнее быть рядом с точкой входа в программу. Вот, если бы мы текст вводили на пол-страницы, то делегировали бы его разбор новому классу.
