Object-based programming allows us to use a single object as though it were any of its superclasses. Conversely, if we are using an object that is of an abstract class type, we are really using one of its subclasses. While we don't need to know which one when we are using the object, obviously at the creation time, the object's actual type is required. The Abstract Factory pattern is designed to decouple the creation of the objects from the code wanting some object. This is typically used when we have a set of abstract base types that we are using. For each of these types, there are several concrete subclasses. If we can logically group a set of concrete subclasses that covers the set of abstract base classes in a 1 to 1 manner, we can create a factory for that set. If we can create several of these factories, then we can create an interface for these factories and use that throughout the program. Then, only the creation of the factory would need to be changed in order to change the whole program such that it used a different set of subclasses.
Java's "look and feel" settings could be implemented using the Abstract Factory pattern, combined with the Strategy pattern. There is the Java look, the Windows look, the Mac look, and at least one Unix look. Each of these could be a concrete factory (with only the allowed "look and feel"s for each platform) that provides the basic building blocks of the GUI system. But, because they want this to be completely transparent to the user, they seem to be using the Strategy pattern to encapsulate all of the factories. The AbstractFactory interface becomes the Strategy interface, and each ConcreteFactory is a ConcreteStrategy. So, in order to switch the "look and feel" of the entire system, you set the strategy pointer to the correct ConcreteFactory. Obviously, there must be extra code to handle the ability to switch from one "look and feel" to another in the middle of execution, but that is another issue entirely.