Стараетесь ли вы поддерживать низкое расстояние от основной последовательности для каждой сборки? Как насчет сборок, содержащих только определения Business Objects? Можно ли держать их подальше от Zone of Pain? Типы в таких сборках обычно используются другими сборками и достаточно конкретны. Как справиться с такой ситуацией?
Метрики Nзависят от сборок
Ответы (1)
Я считаю, что цель {сохранения «расстояния от главной последовательности» на низком уровне} основана на Законе Деметры< /а>. Следование этому правилу помогает сделать ваш код более понятным и простым для модульного тестирования. Используя бизнес-объекты, которые являются простыми контейнерами данных, вы раскрываете больше состояний, чем это может быть необходимо, и нарушаете правила инкапсуляции.
Однако, как указывает в этой статье Фаулер, "Хотя цепочки методов - это запах, обратная проблема объектов посредников, раздутых методами пересылки, также является запахом (я всегда чувствовал, что мне было бы удобнее с Законом Деметры, если бы он назывался Предложением Деметры).
Я думаю, что значение таких базовых бизнес-объектов может быть полезным, если вы хотите передать только то, «что» содержит объект, например, как они используются в качестве объектов передачи данных. Однако, вероятно, важно отличать ваши настоящие бизнес-объекты от ваших пустых объектов передачи данных. Я бы предположил, что настоящие бизнес-объекты должны также содержать поведение вместе с данными, которые они инкапсулируют.