Да, технически это является нарушением закона Деметры, если его описывать в терминах методов. Тем не менее, способ исправить это можно было бы сделать так: добавить операцию типа "keysIterator" в класс Map , и это может быть разумным действием, за исключением того, что здесь Map не ваша код .
Цель Закона Деметры - уменьшить взаимосвязь между компонентами вашего приложения . Изменение того, как вы используете стандартные объекты библиотеки, на это не влияет. Ваше предлагаемое решение неэффективно расходует ресурсы и не имеет особой выгоды.
С другой стороны, набор ключей карты - это просто аспект карты. Вы должны думать об этом не столько как о третьем объекте (где LoD, по сути, говорит, что в любом взаимодействии не должно быть более двух объектов), как о способе классификации операций, которые предоставляет Карта.
Представьте себе другой сценарий: предположим, у вас есть класс приложения , например, категория в интернет-магазине. Было бы значимым нарушением LoD иметь
category.itemsSet().iterator()
и это то, что вы можете реорганизовать. Зачем? Поскольку он ограничивает класс Category для реализации Set, даже если единственная операция, которая действительно необходима, это итерация (или, как правило, меньшее количество операций, чем имеет интерфейс Set), а не реализация, которая выполняет только необходимую работу и может быть исправлено или переопределено легче
С другой стороны, если вещи, которые вы хотите сделать с категорией, охватывают все операции Set, то глупо не предоставлять Category.itemsSet() фасет.
Примечание: «Фасет» здесь означает объект, который находится в отношении 1: 1 к другому объекту и, по сути, представляет собой другое представление «того же самого», особенно более узкое представление. Это не совсем стандартный термин.