When new can conflict with DIP

Direct Answer

new is not automatically a DIP violation. Every object must be constructed somewhere. It becomes a design problem when high-level policy creates a changeable low-level service inside itself and therefore owns both selection and use. Construct value objects and private implementation details normally; assemble replaceable external collaborators in a composition root or factory.

Code Example

// High-level policy selects a vendor detail itself.
final class OrderService {
    void process(long orderId) {
        OrderRepository repository = new MySqlOrderRepository();
        Order order = repository.findById(orderId);
        repository.save(order);
    }
}

// Policy receives the capability; bootstrap code selects the adapter.
final class OrderService {
    private final OrderRepository repository;

    OrderService(OrderRepository repository) {
        this.repository = repository;
    }

    void process(long orderId) {
        Order order = repository.findById(orderId);
        repository.save(order);
        Money fee = new Money(100); // ordinary value construction
    }
}

OrderService service = new OrderService(new MySqlOrderRepository());

The first design is problematic when the repository is a volatile boundary the policy should not choose. The last line still uses new, but it does so at the assembly boundary where concrete implementations must be selected.

Common Mistakes & Pitfalls

• Banning new from business code: value construction is normal.
• Moving every object to a DI container: containers are not needed for local values and simple private helpers.
• Injecting a concrete vendor and calling it DIP: construction moved, but source dependency may still point outward.
• Creating interfaces without a useful contract: indirection alone is not inversion.
• Ignoring the composition root: concrete implementations must be chosen somewhere.