Let’s consider this requirement

You want to build a dashboard application for your user’s data.

You want to give flexibility to your user to provide the data either in some flat file or Excel or in SQL database, whatever the end user is comfortable with.

Builder pattern is good for such scenario. You first build an abstract class, say DataSourceBuilder, implementing a method – lets say – getDataFromSource.
Then you build three classes for the three data sources deriving from above abstract class – FlatFileDataSourceBuilder, ExcelDataSourceBuilder and SQLDataSourceBuilder.
Each one will implement the complex code for getting the data from its respective data source in its overridden version of getDataFromSource.

Then you build a Director class – lets call it – DashboardDirector.
In this ‘DashboardDirector’ class, implement a method – ReadUserData – with a parameter of type – DataSourceBuilder – the abstract class that above builder classes derive from. Let’s call this parameter – paramDataSource.

This method can then call the method – paramDataSource.getDataFromSource – to get the data from whatever data source the parameter ‘paramDataSource’ is for, without worrying about the actual implemetion of complex logic involved in reading data from the three types of data source.

The client application case class now shows three options to the user – FlatFile, Excel, or SQL; and based on what selection the user makes, creates the respective Builder class and passes it on as parameter to DashboardDirector’s ReadUserData method.

After reading the data, the client application continues with the code to build and present the dashboard using that data.