Давайте обратимся к очевидному противоречию между пунктами 22 и 41 книги:

Пункт 22: «Если вы не хотите определять тип, не используйте интерфейс».

Этот пункт предполагает, что вам не следует использовать интерфейсы для вещей, которые не представляют реальный тип или конкретную функциональность. Например, использование интерфейса только для хранения констант не является хорошей практикой. Интерфейсы следует использовать для определения контрактов или поведения, которые должны реализовывать классы.

Пункт 41: «Если вы действительно хотите определить тип, используйте интерфейс».

В этом пункте рассказывается об использовании интерфейсов, в частности интерфейсов-маркеров, для определения типа, который классифицирует или маркирует классы таким образом, чтобы это можно было проверить во время компиляции. Интерфейс маркера не определяет методы, но все же определяет логический тип, который можно использовать для проверки поведения классов во время компиляции.

Сверка позиций

Ключом к пониманию обоих пунктов является разница между определением полезного типа и соответствующим использованием интерфейса.

• Пункт 22 гласит, что следует избегать использования интерфейсов для вещей, с которыми не связана определенная функциональность или поведение. Идея состоит в том, что интерфейсы должны использоваться для определения четких контрактов, которым должны следовать классы.

• Совет 41 рекомендует использовать интерфейсы (включая маркеры), если вы хотите определить тип, который классифицирует или помечает классы для определенной цели и может использоваться для проверки во время компиляции.

Практическое применение
Пункт 22. Избегайте этого:

public interface Constants {
    String SOME_CONSTANT = "value";
    int ANOTHER_CONSTANT = 42;
}

Это не определяет тип или поведение; это просто контейнер констант, что является плохим использованием интерфейса.

Пункт 41. Используйте интерфейсы для обозначения типа:

public interface PhysicalProduct {
    // Interface marcadora sem métodos
}

public class Book implements PhysicalProduct {
    // Implementação da classe que indica que é um produto físico
}

Здесь интерфейс PhysicalProduct определяет логический тип, который можно проверять и использовать для конкретных целей, например для расчета доставки, гарантируя, что учитываются только физические продукты.

Заключение
Оба пункта дополняют друг друга, предоставляя рекомендации о том, как и когда правильно использовать интерфейсы. Идея состоит в том, что интерфейсы должны использоваться для определения значимых типов и четких контрактов, будь то с помощью методов, определяющих поведение, или в качестве маркеров, которые логически и полезно классифицируют классы.