The first one is pretty easy to spot: we are not using the Injection at all. Instead of being Injected, the dependency is instantiated inside the object that depends on it:
class FeaturedProductsController {
private let restProductsService: ProductsService
init() {
self.restProductsService = RestProductsService(configuration: Configuration.loadFromBundleId())
}
}
In this example, ProductsService could have been injected in the constructor but it is instantiated there instead.
Mark Seeman, in his book "Dependency Injection in NET", Chapter 5.1 - DI anti-patterns, calls it Control Freak because it describes a class that will not relinquish its dependencies.
The Control Freak is the dominant DI anti-pattern and it happens every time a class directly instantiates its dependencies, instead of relying on the Inversion of Control for that. In the case of the example, even though the rest of the class is programmed against an interface, there is no way of changing the actual implementation of ProductsService and the type of concrete class that it is, it will always be RestProductsService. The only way to change it is to modify the code and compile it again, but with DI it should be possible to change the behavior at runtime.
Sometimes, someone tries to fix the Control Freak anti-pattern using the factory pattern, but the reality is that the only way to fix it is to apply the Inversion of Control for the dependency and inject it in the constructor:
class FeaturedProductsController {
private let productsService: ProductsService
init(service: ProductsService) {
self.productsService = service
}
}
As already mentioned, Control Freak is the most common DI anti-pattern; pay particular attention so you don't slip into its trap.