Экстремальное программирование. Разработка через тестирование

Нуль-объект (Null Object)
Как реализовать специальные случаи использования объектов?
Созд ать специальный объект, пред ставляющий собой специальный
случай. Специальный объект д олжен облад ать точно таким же
протоколом, что и обычный объект, но он д олжен вести себя
специальным образом.
В качестве примера рассмотрим код , который я позаимствовал из
java.io.File:
java.io.File
public boolean setReadOnly() {
SecurityManager guard = System.getSecurityManager();
if (guard!= null) {
guard.canWrite(path);
}
return fileSystem.setReadOnly(this);
}
В классе java.io.File можно обнаружить 18 проверок guard!= null. Я
преклоняюсь перед усерд ием, с которым разработчики библиотек Java
стараются сд елать файлы безопасными д ля всего о стального мира,
од нако я также начинаю немножко нервничать. Буд ут ли программисты
Oracle и в буд ущем столь же аккуратны, чтобы не забыть проверить
результат выполнения метод а getSecurityManager() на равенство
значению null?
В рамках альтернативного решения можно созд ать новый класс
LaxSecurity, который вообще не генерирует исключений:
LaxSecurity
public void canWrite(String path) {
}
Если 
кто-то 
пытается 
получить 
SecurityManager, 
од нако
пред о ставить такой объект нет возможно сти, вместо него мы
возвращаем LaxSecurity:
SecurityManager

---

public static SecurityManager getSecurityManager() {
return security == null? new LaxSecurity(): security;
}
Теперь мы можем не беспокоиться о том, что кто-то забуд ет
проверить результат выполнения метод а на равенство значению null.
Изначальный код становится существенно более чистым:
File
public boolean setReadOnly() {
SecurityManager security = System.getSecurityManager();
security.canWrite(path);
return fileSystem.setReadOnly(this);
}
Од нажд ы во время выступления на конференции OOPSLA нас с Эр
ихом Гаммой (Erich Gamma) спро сили, можно ли использовать
«Нуль-объект» (Null Object) в рамках од ного из классов JHotDraw. Я
принялся рассужд ать о преимуществах такой мод ернизации, в то время
как Эрих по считал, что д ля этого нам прид ется увеличить код на д есять
строк, при этом мы избавимся от од ного условного оператора –
преимущество сомнительно. (К тому же ауд итория была весьма
нед овольна нашей несогласованно стью.)