There are programming/development guidelines, heuristics, principles or patterns that, when realized, span their initial scope supporting other goals. These principles in many cases are very concrete and local but its effects go to cover other parts of the software, like a whole subsystem or a package.

The use of the factory method is one of those principles. The implementation of a factory method implies the use of an abstract type that receive the concrete object via late-binding. The variable in the class is an interface or an abstract class complying with the well-known principle of «program to interfaces not to implementations». But it’s not the unique principle we respect with this implementation. The DIP («dependency inversion principle») also is supported with the pattern because the calling class can be in another package of the called class only connected by  an interface. Then, the factory method can replace the concrete instance with another one from other package that implements the expected interfaces.

After all, programming isn’t about concrete implementations only. Programming is about designing algorithms to accomplished a system operation or goal. This part of  the programming process mirrors the design of the software, where the system shows its actions and capabilities.  The implementation with concrete classes are another step under the construction process when all specific alternatives are evaluated and decided. That part of the programming process shows the technical abilities of the software, to perform the system operations quickly and secure, without flaws.