When we use `Abstract Factory Pattern`, we generally have `FactoryMaker` class which has a `getFactory` function in which we pass argument and we have `switch` or `if-else` logic in the function on the passed parameter to decide which factory to return. Is creating passed parameter an enum or an object and then having the logic of which factory to return inside those object will be better. For example : 

Let us say this us our factory maker which are passed enum CountryCode to decide factory. 

```

    public class FacoryMaker {

        public final static FacoryMaker fctry= new FacoryMaker();

        public static RetailFactory getFactory(CountryCode code){
            RetailFactory rt = null;
            if(code == CountryCode.UK){
                rt = new UKFactory();
            }
            if(code == CountryCode.US){
                rt = new USFactory();
            }
            return rt;
        }
    }

```

Instead of this we will have :

```

    public class FacoryMaker {

        public final static FacoryMaker fctry= new FacoryMaker();

        public static RetailFactory getFactory(CountryCode code){
            return code.getFactory();
        }
    }

```

and enum will be modified like this:

```

    public enum CountryCode {
        US(){
            @Override
            public RetailFactory getFactory() {
                return new USFactory();
            }
        },  
        UK(){
            @Override
            public RetailFactory getFactory() {
                return new UKFactory();
            }
        };  
        public abstract RetailFactory getFactory();
    }

```

But I don't see this being followed generally. Why is it so? Why can't we make the passing parameter always an object and have the logic inside the object of which factory to get? Can it fail under any abstract factory design. It looks very generic to me. Also by this it is possible to even remove the factory maker and use the object directly to get the Factory instance.