Depend on abstractions. Do not depend on concrete classes [closed]

Question

While i was reading factory , abstract factory design patterns on head first design pattern book. It mentioned about the phrase.

Could you give an basic example and explanation to clarify it.

Answer 1

Dependency Inversion Principle; One of the five Object Oriented Design Principles. Check out the answers to this question; "What is the Dependency Inversion Principle and why is it important?" - there's some really good information there.

In conventional application architecture, lower-level components are designed to be consumed by higher-level components which enable increasingly complex systems to be built. In this composition, higher-level components depend directly upon lower-level components to achieve some task. This dependency upon lower-level components limits the reuse opportunities of the higher-level components.

In 'simple' terms, this means that when you rely upon a concrete instance of an object - you're building a dependency in to your code (albeit without that intention), this then limits the ability to re-use it.

Remember that a Concrete Type is a type of class that can be instantiated and a Abstract Type is a type that cannot; i.e an interface. (See the Taxonomy of Classes)

If you code to a specific concrete class then you will always have the requirement for that class. However, if you code to an interface (an abstraction) then it's possible to adapt your code to work with any number of classes; as long as they implement that common interface.

So in Java, it means that where possible you should code to an Interface - and avoid making your code depend on specific items. This is often as simple as passing Interface types as parameters and return types; as opposed to concrete classes.

Less dependencies = More ability to re-use code. More dependencies = More requirements to be able to re-use code.

This will be a re-occuring theme when you're studying Design Patterns!

Dependency Inversion Principle on Wikipedia.

Answer 2

Because factories are virtual constructors. They give you the ability to return different types at runtime. Factories depend on polymorphism.

You can't do any such thing if you return concrete types.

public interface IFoo {
    void execute();
}

public class Bar implements IFoo {
    public void execute() { System.out.println("Bar does one thing"); }
}

public class Baz implements IFoo {
    public void execute() { System.out.println("Baz does another"); }
}

public class FooFactory { 
    private static final FooFactory instance = new FooFactory(); 

    private FooFactory() {}

    public static final FooFactory getInstance() { return instance; }

    public IFoo create(Class clazz) { 
        return clazz.newInstance();
    }
}

It should be obvious that if you return an Bar from the create method that a Baz is impossible and visa versa. The interface is the key.