Let's address the apparent contradiction between items 22 and 41 of the book:

Item 22: “If you don’t want to define a type, don’t use an interface.”

This item suggests that you shouldn't use interfaces for things that don't represent a real type or concrete functionality. For example, using an interface just to store constants is not a good practice. Interfaces should be used to define contracts or behaviors that classes should implement.

Item 41: “If you really want to define a type, use an interface.”

This item talks about using interfaces, specifically marker interfaces, to define a type that categorizes or marks classes in a way that can be checked at compile time. A marker interface does not define methods, but it still defines a logical type that can be used to check the behavior of classes at compile time.

Reconciling the Items

The key to understanding both items is the difference between defining a useful type and using an interface appropriately.

• Item 22 says to avoid using interfaces for things that don't have specific functionality or behavior associated with them. The idea is that interfaces should be used to define clear contracts that classes must follow.

• Item 41 recommends using interfaces (including markers) when you want to define a type that categorizes or marks classes for a specific purpose and that can be used for compile-time checking.

Practical Application
Item 22: Avoid this:

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

This does not define a type or behavior; it's just a container of constants, which is a bad use of an interface.

Item 41: Use interfaces to mark a type:

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

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

Here, the PhysicalProduct interface defines a logical type that can be checked and used for specific purposes, such as shipping calculation, ensuring that only physical products are considered.

Conclusion
Both items complement each other by providing guidance on how and when to use interfaces appropriately. The premise is that interfaces should be used to define meaningful types and clear contracts, whether through methods that define behavior or as markers that categorize classes in a logical and useful way.