Item 22: Use interfaces only to define types

Interfaces should be used only to define types. They should not be used merely to export constants. The constant interface pattern is a poor use of interfaces If the constants are best viewed as members of an enumerated type, you should export them with an enum type (Item 34) If the constants are NOT strongly […]

Item 20: Prefer interfaces to abstract classes

Advantages Existing classes can easily be reconstructed to implement a new interface. You just need to use implements clause to the class declaration and add the required methods Interfaces are ideal for defining mixins (Example: Interfaces allow for the construction of non-hierarchical type frameworks. They are great for organizing things that don’t fall into a hierarchy […]

Item 18: Favor composition over inheritance

Inheritance violates encapsulation unless the superclass’s authors have designed it specifically for the purpose of being extended The superclass’s implementation may change from release to release, and if it does, the subclass may break, even though its code has not been touched. As a consequence, a subclass must evolve in tandem with its superclass, unless […]

Item 17: Minimize Mutability

An immutable class is simply a class whose instances cannot be modified. All of the information contained in each instance is fixed for the lifetime of the object, so no changes can ever be observed. An immutable object can be in exactly one state, the state in which it was created Immutable objects are inherently […]

Item 15: Minimize the accessibility of classes and members

Encapsulation A well-designed component hides all its implementation details, cleanly separating its API from its implementation. Components then communicate only through their APIs and are oblivious to each others’ inner workings. This concept, known as information hiding or encapsulation, is a fundamental tenet of software design. The advantages of encapsulation are as follows: Speeds up […]