Singletons are dependencies

For instance, in this code

Date now = new Date();

now is created from the singleton call to System.currentTimeMillis(), which is bad.

To remove this dependency, use a Clock object that can be passed to the code.

The clock object can thus be used to change the date emitted and the dependency is removed.

One goal of object orientation as a technique for structuring code is to make the boundaries of an object clearly visible. An object should only deal with values and instances of an object clearly visible. An object should only deal with values and instances that are either local—created and managed within its scope—or passed in explicitly, as we emphasized in “Context Independence”

Do not mock concrete class we doing so forces the class being tested depend on interfaces that it does not use. Mock the interface using descriptive mock object that would more aptly describe the function of the object. For instance, use ShedulingDevice to mock CDPlayer interface.

If an immutable value is too complicated to set up, consider writing a builder.

Bloated constructor – too many arguments that are used by different objects that are also passed as arguments.

For instance, refactor the following:

Obj (class1 obj1, class2 obj2, int arg1, int arg2) {

obj1.setarg1(arg1);

obj2.setarg2(arg2);

}

to

Obj (class1 obj1, class2 obj2) {

}

where arg1 and arg2 are already injected into obj1 and obj2.

Bloated constructor 2 – object tries to do too many thins and thus need many arguments for different functions

Bloated constructor 3 – too many dependency to begin with – dependencies should all be final. All those can be initialized to common defaults and customized using setters.