Creational Patterns  «Prev  Next»
Lesson 3 How do creational patterns help programmers?
Objective Example of how Creational Patterns are Used.

Example of how Creational Patterns are Used

Creational patterns hide many details from programmers. For example, the Java core API[1] uses the Factory Method pattern to create URLConnection objects. This specific Factory Method is openConnection() in the java.net.URL class.

          
public URLConnection openConnection() 
throws IOException

URLConnection is an Abstract Class[2]
Concrete subclasses represent connections to many different kinds of servers including HTTP, FTP, SMTP, NNTP, and more. Each of these concrete subclasses has to speak a different protocol and behave a little differently. However, client programmers (the people who use this class) don't care about these details. They just need to read from input streams and write to output streams.


The interface a client programmer sees is the same generic URLConnection interface whether or not they are talking to a Web server, an FTP server, or a news server. Since the subclass names are not hard coded into the program, additional subclasses that handle additional protocols can be added at later times without even recompiling any code. Indeed this design pattern lies at the foundation of Java's much-hyped protocol handler mechanism.

This is an excellent use of a creational design pattern to enhance flexibility about what gets created. Creational design patterns can also be used
  1. to increase the flexibility with respect to who creates an object,
  2. how the client creates the object, and
  3. when the object is created.

Abstract classes are defined so that other classes can extend them and make them concrete by implementing the abstract methods.

[1]Application Programming Interface: The API specifies the method used by a programmer when writing an application to access the behavior and state of classes and objects.
[2]Abstract Class: A class that contains one or more abstract methods, and therefore can never be instantiated.