Good examples of the factory pattern point out why it is necessary to abstract away the creation of an object.

Your example is functional, it works, but it fails to provide a convincing reason to choose this design over a different, much simpler one:

- one stuct for footwear

- one struct for discounts

- one function for applying discounts to the final bill

Points of critique

- Shoe and Slipper are functionally identical; one struct is obviously sufficient

- adding a field for style would simplify the structs even more

- using enums might be a good idea

- interfaces don't start with a `I` in Go

A alternative example

There are different discounts which should come from a factory. Seasonal discounts, manual discounts which should be applied, coupons, ... That's what might be interesting to model as the behaviour.

Factories are specifically interesting for the creation types implementing interfaces, that provide different behavior. In the case of discounts it would be discounts that are applied only on single items, the complete shopping cart, are one applicable at certain times of the day ...