Should interface packages have also the factory mechanism for concrete instances creation? That question arrives in all implementation of DIP (Dependency-inversion principle), when the interfaces that connect the concrete components are isolated into their own package. Also is apparent in the GRASP principles, whereas Creator principle is answered by who should create an object.

When using DIP and layers architectural patterns, the interfaces and abstracts are enclosed in separate packages to avoid dependencies with implementations. They define the system operations or algorithms, that should be implemented by its derivables (subtypes and subclasses). In compliance to the principle that recommend the use of classes variables at the most abstract level (abstract classes or interfaces) the problem of instantiation spreads everywhere. The most useful solution is to use a factory method that child or derivables must override. The Factory.Making[ObjectName] formula is a common solution to delegate the details of instantiation to children. But where do we put the Factory? In the Children package? In the Caller class that need to instantiate the concrete?

A good solution that also support late or dynamic-binding is to define Factories in the interface or abstract classes packages. The factory methods could use reflection or class loaders to instantiate concrete classes by configuration data in any source. That configuration data would reside in XML or initialization files or a database. The caller classes that use the interface or abstract variable avoid the propagation of dependencies, when they only need to know about the package of interfaces. In other situations, when the use of factories aren’t recommended, the interface or abstract class could use the same factory methods mechanism to delegate concrete instantiation to children.