In our product, the fulfilment is done by external sellers. For institutional sellers, there is an external API that needs to be called to perform actions such as booking. Suppose an institutional seller, say HotelBoutique, gives a REST API (more on API types in a follow-up chapter); how should the system interact with this external agent? Obviously, the first thought that comes to our mind is to encapsulate and isolate the HotelBoutique specifics in one place.

A proxy is essentially a class functioning as an interface to something else. It is an object that delegates the work to the subject (that which is being proxied) and abstracts clients from the subject specifics. The specifics include the location, so this allows cool design where the client and the subject may or may not be in the same compiled binary, but the rest of the code works without any change.

The proxy delegation can simply be forwarding, or it can provide additional logic (for example, caching).

For the HotelBoutique example, the proxy pattern, with a dummy class instead of the API call, is given here:

// Proxy
type HotelBoutiqueProxy struct {
    subject *HotelBoutique
}

func (p *HotelBoutiqueProxy) Book() {
    if p.subject == nil {
        p.subject = new(HotelBoutique)
    }

    fmt.Println("Proxy Delegating Booking call")

    // The API call will happen here
    // For example sake a simple delegation  is implemented
    p.subject.Book()
}

// Dummy Subject
type HotelBoutique struct{}

func (s *HotelBoutique) Book() {
    fmt.Println("Booking done on external site")
}