Null Object Pattern

  • 14
  • Недоступна
Почитай на вики про паттерн "Null Object". Используй Files, чтобы в конструкторе класса Solution правильно инициализировать поле fileData объектом ConcreteFileData. Если возникли какие-то проблемы со чтением файла по пути pathToFile, то инициализируй поле объектом NullFileData.
Вы не можете решать эту задачу, т.к. не залогинены.
Комментарии (75)
  • популярные
  • новые
  • старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
Дмитрий Б.
Уровень 29, Благовещенск, Россия
15 сентября, 08:08
Написал строчку Path path = Paths.get(pathToFile); чтобы упростить писанину при инициализации FileData, но нет же, Валя хочет чтоб ты Paths.get(pathToFile) прописал 4 раза.
bprint
Уровень 26
22 сентября, 06:00
А у меня прокатила эта строчка. Странно...
Maks Panteleev
Уровень 41, Москва, Россия
25 июня, 07:37
Смысл в том, что иногда возвращение null приводит к всем известной ошибке. Чтоб спокойно возвращать ничего и не иметь проблем, используется паттерн "нулевой объект". Это когда мы вместо null возвращаем специально созданный пустой объект. "Болванку" некоторую
Aleksandr Alekseenko Network engineer
14 июня, 00:06
В блоке try использовал одну строчку fileData = new ConcreteFileData(Files.isHidden(path), Files.isExecutable(path), Files.isDirectory(path), Files.isWritable(path)); А в catch, вроде бы и так понятно, что писать.
Davilalexius
Уровень 37, Москва, Россия
11 апреля, 15:57
Зачем-то проверял в начале на if (Files.isReadable(Path)){тогда всё остальное}. Видимо для экономии процессорного времени, если файла вообще не существует)))) Делайте проверки, только те что в интерфейсе)
Regina Kazan Start-up Founder / AT QA в jivys.com
6 апреля, 16:31
одна из тех задач, которая получилась с первого раза по наитию
mbesurich Android Developer в Й1
1 марта, 20:13
не понимаю, что не нравится валидатору! подсмотрел правильный ответ и не нашёл принципиальной разницы с моём решением. Подскажите, плиз, кто может, почему у меня ни одно условие не выполнено?
Данил
Уровень 27
9 июня, 05:02
Нужно использовать Files, а не File. Почему-то старые классы валику не нравятся
Aleksandr
Уровень 41
18 декабря 2020, 08:47
Совершенно непонятно зачем, для чего, куда, как . но вы пишите , пишите. может что и поймете. Всё больше и чаще задачи идут делай что-то, может поймешь для чего оно и зачем. А уж как решать проблемы твои, теорию мы тебе конечно же не расскажем.
Maks Panteleev
Уровень 41, Москва, Россия
25 июня, 07:36
А что тут непонятного то? Нас быстро и легко обучили паттерну нулевой объект.
Bonus
Уровень 35
12 ноября 2020, 15:08
Через условие if (Files.exists) валик не принимает только через try и создание NullObject в catch
Dmitry
Уровень 31, Хабаровск, Россия
16 ноября 2020, 02:07
Да, сначала тоже так подумалось делать. Но все дороги в любом случае ведут в try catch, idea не хочет Files.isHiden(...) проверять без обработки IOException.
Андрей
Уровень 37, Москва, Россия
23 октября 2020, 00:20
Важно в try не запихивать лишнего, а начинать его с
Files.isReadable(Paths.get(pathToFile));
Иначе работать будет нормально, но валик будет бесчинствовать.
Mike
Уровень 35, Москва, Россия
8 ноября 2020, 17:29
Я такого не писал, принял нормально.
Ivan D
Уровень 35
16 ноября 2020, 09:50
ридабле не писал, все работает.
Maxim Работает в СберТех
30 апреля, 16:55
Фух, спасибо А я просто создавал новый объект Path. Поменял на
Paths.get(pathToFile)
и валик сразу принял!
максим
Уровень 40, Екатеринбург
23 июля 2020, 11:58
Хотел упростить задачу до Files.Exists(), но вали не принял, нужна непосредственная проверка в конструкторе ConcreteFileData