Introduction:
Facade design pattern provides simple and easy to use interface to a larger and more complex code, API or set of APIs.
If you have to deal with complex or poorly designed API you might find yourself confused by all the functionality available in it. Most likely you don’t need everything provided by the API. So for ease and better maintainability, only API features that are needed gets exposed outside the facade. In this way, you simplify the API usage saving time for your colleagues when maintaining this code. Also, you have control over how this external API is used and can prevent misunderstanding or misuse of it. If more functionality from API is needed this will require an update of the facade or adding new facade which exposes it.
Example:
It might not be a good idea to have the pattern in the name of the facade, but in the example, I’ve put it to ease. In this example, WebDriver instantiation is hardcoded to Firefox, but in real life, it will be instantiated based on some rules. Facade exposes Start, Stop and FindElement methods. All other WebDriver functionality is not accessible.
A facade is used exactly the same way as WebDriver itself:
WebDriverFacade webDriver = new WebDriverFacade();
webDriver.Start("https://automationrhapsody.com");
IWebElement logo = webDriver.FindElement(By.CssSelector("div#header-inner h1 a"));
logo.Click();
webDriver.Stop();
Conclusion:
WebDriver API is neither complex nor poorly designed, so maybe making a facade is not a mandatory thing. Still, I think having control over its usage is a good approach. In given example, you can see I use explicit wait so I locate exactly the same way all elements in my automation project.
Building better for tomorrow
Comments