When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.
Please note we have a code of conduct, please follow it in all your interactions with the project.
| #!/bin/bash | |
| # CHANGE THESE | |
| auth_email="[email protected]" | |
| auth_key="c2547eb745079dac9320b638f5e225cf483cc5cfdda41" # found in cloudflare account settings | |
| zone_name="example.com" | |
| record_name="www.example.com" | |
| # MAYBE CHANGE THESE | |
| ip=$(curl -s http://ipv4.icanhazip.com) |
The three design patterns (Adapter, Facade and Bridge) all produce the result of a clean public API. The difference between the patterns are usually due to a subtle context shift (and in some cases, a behavioural requirement).
The primary function of an Adapter is to produce a unified interface for a number of underlying and unrelated objects.
You will notice this pattern being utilised in many applications. For example, ActiveRecord (the popular Ruby ORM; object-relational mapping) creates a unified interface as part of its API but the code underneath the interface is able to communicate with many different types of databases. Allowing the consumer of the API to not have to worry about specific database implementation details.
The principle structure of this pattern is: