Varieties of Manufacturers

The idea behind the Factory design patterns is to encapsulate the creation of instances of classes, the responsibility for which is delegated to classes specializing in the creation of such instances. There are three different varieties of Factory design patterns, but the primary purpose of all of them is to create instances of classes. They are

1. Simple Factory :¹ More idiom than design pattern

2. Factory Method : Uses class inheritance (“is a”)

3. Abstract Factory : Uses class composition (“has a”)

Whereas the Simple Factory is not covered by GoF , both the Factory Method and Abstract Factory are categorized by GoF with a creational purpose; they differ in that Factory Method has a class scope while Abstract Factory has an object scope.

Simple Factory Design Pattern

A Simple Factory for creating classes is characterized by the following:

• The class definition includes the “create private ” qualifier, meaning no entity other than the class itself can create instances of the class.

• The class is defined with a publicly visible static method by which external entities may request an instance of the class be created.

Providing the “create private ” qualifier to a class confers complete control to the class over the creation of any of its instances, forcing other entities requiring an instance of the class to request an instance instead of creating one themselves.

Simple Factory in ABAP

Listing 14-1 shows an example of using the Simple Factory pattern to control the instantiation of car classes.

Listing 14-1. Simple Factory Pattern Controlling the Instantiation of car Classes

class car definition create private.
  public section.
    class-methods: get_instance
                     exporting instance type ref to car.
    methods      : start
                 , stop
                     o
                     o
endclass.
class car implementation.
   method get_instance.
     create object instance.
   endmethod.
   method start.
     o
     o
   endmethod.
   method stop.
     o
     o
   endmethod.
     o
     o
endclass.

The operative phrase for the car definition above is create private. It means that no entities other than the car class are capable of creating instances of cars. The implementation for the static method get_instance shows that it will create an instance of a car to be returned to the caller. Once created and returned to the caller via the instance reference parameter, the caller can now use the instance reference to invoke the public instance methods defined by the car class.

A good example of this is the standard SAP class cl_salv_table, one of the collection of classes that makes up the ALV Object Model framework. If you look at the definition of this global class via the SE24 transaction, you can see that it is marked as create private by virtue of the value “private” assigned to the Instantiation property on its Properties tab. It is also accompanied by a publicly visible static method named factory, by which instances of cl_salv_table can be requested by external entities. Indeed, the accompanying exercise programs have been invoking this static method to create ALV table instances since the very first exercise.

Simple Factory Similarity with Singleton

Simple Factory and Singleton both include the create private qualifier on the class definition statement, insuring that only the class itself is capable of creating its own instances. They differ in that Singleton has a mechanism by which to insure that only one instance ever becomes available during execution, while Simple Factory allows unlimited instances of its class to be created.²

Factory Method in ABAP

The following code shows how we might implement the Factory Method design pattern UML class diagram illustrated above into functioning ABAP code. First, the classes are defined to represent the product to be produced by the Factory Method. Listing 14-2 shows the code for the navigation_unit class.

Listing 14-2. Code for the navigation_unit Class

class navigation_unit definition abstract.
  public section.
    types        : compass_point  type char1.
    methods      : get_heading abstract
                     exporting heading type compass_point
                 , set_heading abstract
                     importing heading type compass_point
                 .
endclass.

This code shows the abstract class for the navigation_unit playing the role of the Product participant. In Listing 14-3, we see the gps class inheriting from it, playing the role of the ConcreteProduct participant.

Listing 14-3. Code for the gps Class

class gps definition inheriting from navigation_unit.
  public section.
    methods      : get_heading redefinition
                 , set_heading redefinition
                 .
  private section.
    data         : heading type navigation_unit=>compass_point.
endclass.
class gps implementation.
  method get_heading.
    heading                       = me->heading.
  endmethod.
  method set_heading.
    me->heading                   = heading.
  endmethod.
endclass.

Next, Listing 14-4 contains the classes that define the components representing the factory.

Listing 14-4. Classes That Define the Components Representing the Factory

class navigation_unit_factory definition abstract.
  public section.
    methods      : manufacture_navigation_unit
                     exporting navigator type ref to navigation_unit.
  protected section.
    methods      : create_unit abstract
                     exporting navigator type ref to navigation_unit.
  private section.
    methods      : calibrate_unit
                     importing navigator type ref to navigation_unit
                 , register_unit
                     importing navigator type ref to navigation_unit
                 .
endclass.
class navigation_unit_factory implementation.
  method manufacture_navigation_unit.
    call method me->create_unit
      importing navigator         = navigator.
    call method me->calibrate_unit
      exporting navigator         = navigator.
    call method me->register_unit
      exporting navigator         = navigator.
  endmethod.
  method calibrate_unit.
    calibrate the navigator
  endmethod.
  method register_unit.
    register the navigator
  endmethod.
endclass.

In Listing 14-4, we see the abstract class for navigation_unit_factory playing the role of the Creator participant. Notice that it defines abstract protected method create_unit, which requires this entire class to be defined as abstract as well as relieving it from providing an implementation for this method. Its private methods facilitate calibrating and registering a navigation unit. Its public method, enabling callers to get a new instance of a fully calibrated and registered navigation unit returned to them, invokes the methods create_unit, calibrate_unit, and register_unit, in that sequence. The abstract method create_unit, implemented by a subclass, is responsible for creating a concrete instance of a navigation unit, which is then calibrated and registered by the methods of this class. Accordingly, the processing taking place in this class knows nothing about the specific concrete class of navigation_unit it is calibrating and registering.

In Listing 14-5, we see the gps_unit_factory class inheriting from the navigation_unit_factory class, playing the role of the ConcreteProduct participant. Notice that it provides an implementation for the abstract method create_unit defined by its superclass. Notice also that the implementation for the create_unit method simply creates an instance of a navigation unit of type GPS.

Listing 14-5. Class gps_unit_factory

class gps_unit_factory definition
                       inheriting from navigation_unit_factory.
  protected section.
    methods      : create_unit redefinition.
endclass.
class gps_unit_factory implementation.
  method create_unit.
    create object navigator type gps.
  endmethod.
endclass.

In this example, the create_unit method is the factory method, the method resulting in the creation of a concrete instance of a navigation_unit. Listing 14-6 shows how these components might be used by other entities.

Listing 14-6. Class car Using the Classes Defined Above

class car definition.
  o
  o
  private section.
    data         : navigator type ref to navigation_unit.
    methods      : get_navigation_unit
                     importing navigation_type type char1.
  o
  o
endclass.
class car implementation.
  o
  o
  method get_navigation_unit.
    data         : navigator_factory type ref to navigation_unit_factory
                 , manufacturer      type seoclsname
                 .
    case navigation_type.
        o
        o
      when global_positioning.
        manufacturer              = 'GPS_UNIT_FACTORY'.
    endcase.
    create object navigator_factory type (manufacturer).
    call method navigator_factory->manufacture_navigation_unit
      importing navigator         = me->navigator.
  endmethod.
endclass.

We see in Listing 14-6 that the car class has a private method get_navigation_unit, which handles determining the relevant type of navigation unit manufacturer, creating an instance of a ConcreteCreator participant of the Factory Method design pattern using the relevant type of navigation unit manufacture, and then invoking a method of that ConcreteCreator to create for it an instance of a navigator product to be used with the car instance.

Abstract Factory Design Pattern

The Abstract Factory design pattern is the last of the factory patterns to be covered, and, as its UML diagram shows, is much more involved than what we have seen so far. It may, at first glance, appear too daunting to comprehend this pattern, but fear not, because we will see an example of its use to help us better understand its power.

The intent behind the Abstract Factory design pattern is the following:

• Provide an interface for creating families of related or dependent objects without specifying their concrete classes. ⁵

Abstract Factory makes use of these participants⁶ working in collaboration with each other:

1. AbstractFactory: Declares an interface for operations that create abstract product objects.

2. ConcreteFactory: Implements the operations to create concrete product objects.

3. AbstractProduct : Declares an interface for a type of product object.

4. ConcreteProduct: Defines a product object to be created by the corresponding concrete factory. Implements the AbstractProduct interface.

5. Client: Uses only interfaces declared by AbstractFactory and AbstractProduct classes.

The following are characteristics of an Abstract Factory design pattern:

• It is known as abstract factory because the client accesses the factory abstractly through an interface instead of working directly with a concrete factory.

• It uses composition ; the client “has a” reference to an abstract factory instance. This reference can point to any one of the several different concrete factories inheriting from abstract factory, each of which is capable of creating a family of related products.

• Once the factory has created instances of the concrete products, the client accesses these instances through an interface, enabling the client to work with the instances created by any one of the concrete factories the same as the instances of any other concrete factory.

The UML class diagram for Abstract Factory is shown in Figure 14-3.

Figure 14-3. UML class diagram for the Abstract Factory design pattern

Notice the client “has a” reference to an instance of an abstractFactory. It also “has a” reference to instances of each abstract product , which will contain a reference to a product produced by the abstractFactory instance. The client interacts with the abstractions and not directly with any of the concrete instances.

The UML class diagram shown in Figure 14-4 is a copy of Figure 14-3 but shows how an abstract factory pattern can be established to create widgets used to compose the windows for presenting content by different internet browsers.

Figure 14-4. UML class diagram for the Abstract Factory design pattern applied to a browser widget scenario

As illustrated in Figure 14-4, the client has a reference to an abstract browserWidgetFactory as well as references to abstract menuBar and ScrollBar widgets produced by this abstract factory. One of the concrete widget factories produces menu bars and scroll bars to be used with the Firefox Internet browser, while another produces menu bars and scroll bars to be used with the Opera Internet browser. The client interacts only with the abstract references.

When a computer user decides to open the Firefox browser, the client program managing this interaction has a concrete Firefox widget factory made available to it through the abstract browserWidgetFactory. This factory produces menu bar and scroll bar widgets for the Firefox family. Accordingly, the user of the browser sees window components composed using only the Firefox family members. This assures a consistent appearance of the windows produced by the Firefox browser during web surfing.

Later, the user decides to close the Firefox browser and open the Opera browser. Now the client program managing this interaction has a concrete Opera widget factory made available to it through the abstract browserWidgetFactory, producing menu bar and scroll bar widgets for the Opera family. Accordingly, the user of the browser sees window components composed using only the Opera family members, assuring a consistent appearance of the windows produced by the Opera browser during web surfing.

As long as the client program uses the abstract factory to supply its menu bars and scroll bars, there is little chance of a browser window being displayed with both a Firefox menu bar and an Opera scroll bar.

Abstract Factory in ABAP

The following code shows how we might implement the Abstract Factory design pattern UML class diagram illustrated above into functioning ABAP code. First, we define an abstract class corresponding to the menuBar abstract class illustrated in the UML diagram in Figure 14-4, playing the role of the AbstractProduct participant and shown in Listing 14-7 with some general public methods applicable to menu bars.

Listing 14-7. Abstract Class menu_bar

class menu_bar definition abstract.
  public section.
    methods      : hover_over_menu_item abstract
                 , left_click_on_menu_item abstract
                 , right_click_on_menu_item abstract
                 .
endclass.

All of these methods are defined as abstract, meaning the class must also be defined as abstract (this would be necessary even if only one method had been defined as abstract) and contains no implementation due to the absence of any non-abstract methods. Listing 14-8 shows the classes inheriting from it, each of which plays the role of the ConcreteProduct participant and provides implementations for the abstract methods defined by the superclass.

Listing 14-8. Concrete menu_bar Classes for Firefox and Opera Browsers

class firefox_menu_bar definition
                       inheriting from menu_bar.
  public section.
    methods      : hover_over_menu_item redefinition
                 , left_click_on_menu_item redefinition
                 , right_click_on_menu_item redefinition
                 .
endclass.
class firefox_menu_bar implementation.
  method hover_over_menu_item.
    do menu bar hovering applicable to firefox
  endmethod.
  method left_click_on_menu_item.
    do menu bar left-click applicable to firefox
  endmethod.
  method right_click_on_menu_item.
    do menu bar right-click applicable to firefox
  endmethod.
endclass.

class opera_menu_bar definition
                       inheriting from menu_bar.
  public section.
    methods      : hover_over_menu_item redefinition
                 , left_click_on_menu_item redefinition
                 , right_click_on_menu_item redefinition
                 .
endclass.
class opera_menu_bar implementation.
  method hover_over_menu_item.
    do menu bar hovering applicable to opera
  endmethod.
  method left_click_on_menu_item.
    do menu bar left-click applicable to opera
  endmethod.
  method right_click_on_menu_item.
    do menu bar right-click applicable to opera
  endmethod.
endclass.

Next are the abstract classes corresponding to the scrollBar abstract class illustrated in the UML diagram in Figure 14-4, also playing the role of the AbstractProduct participant and shown in Listing 14-9 with some general public methods applicable to scroll bars. In this case, there are two classes so we can distinguish between horizontal and vertical scroll bars.

Listing 14-9. Abstract Classes horizontal_scroll_bar and vertical_scroll_bar

class horizontal_scroll_bar definition abstract.
  public section.
    methods      : scroll_left abstract
                 , scroll_right abstract
                 .
endclass.
class vertical_scroll_bar definition abstract.
  public section.
    methods      : scroll_back abstract
                 , scroll_forward abstract
                 .
endclass.

Listing 14-10 shows the classes inheriting from them, each of which again plays the role of the ConcreteProduct partcipant.

Listing 14-10. Concrete Scroll Bar Classes for Firefox and Opera Browsers

class firefox_horizontal_scroll_bar definition
                         inheriting from horizontal_scroll_bar.
                 .
  public section.
    methods      : scroll_left redefinition
                 , scroll_right redefinition
                 .
endclass.
class firefox_horizontal_scroll_bar implementation.
  method scroll_left.
    do scroll left applicable to firefox
  endmethod.
  method scroll_right.
    do scroll right applicable to firefox
  endmethod.
endclass.

class firefox_vertical_scroll_bar definition
                         inheriting from vertical_scroll_bar.
                 .
  public section.
    methods      : scroll_back redefinition
                 , scroll_forward redefinition
                 .
endclass.
class firefox_vertical_scroll_bar implementation.
  method scroll_back.
    do scroll back applicable to firefox
  endmethod.
  method scroll_forward.
    do scroll forward applicable to firefox
  endmethod.
endclass.

class opera_horizontal_scroll_bar definition
                       inheriting from horizontal_scroll_bar.
  public section.
    methods      : scroll_left redefinition
                 , scroll_right redefinition
                 .
endclass.
class opera_horizontal_scroll_bar implementation.
  method scroll_left.
    do scroll left applicable to opera
  endmethod.
  method scroll_right.
    do scroll right applicable to opera
  endmethod.
endclass.

class opera_vertical_scroll_bar definition
                       inheriting from vertical_scroll_bar.
  public section.
    methods      : scroll_back redefinition
                 , scroll_forward redefinition
                 .
endclass.
class opera_vertical_scroll_bar implementation.
  method scroll_back.
    do scroll back applicable to opera
  endmethod. "line 100
  method scroll_forward.
    do scroll forward applicable to opera
  endmethod.
endclass.

Listing 14-11 shows the definition of an abstract class corresponding to the browserWidgetFactory abstract class illustrated in the UML diagram in Figure 14-4, playing the role of the AbstractFactory participant.

Listing 14-11. Class browser_widget_factory

class browser_widget_factory definition abstract.
  public section.
    methods      : create_menu_bar abstract
                     exporting menu type ref to menu_bar
                 , create_horizontal_scroll_bar abstract
                     exporting
                       scroller type ref to horizontal_scroll_bar
                 , create_vertical_scroll_bar abstract
                     exporting
                       scroller type ref to vertical_scroll_bar
                 .
endclass.

Listing 14-12 shows the classes inheriting from it, each playing the role of the ConcreteFactory participant.

Listing 14-12. Concrete Widget Factory Classes for Firefox and Opera Browsers

class firefox_widget_factory definition
                             inheriting from browser_widget_factory.
  public section.
    methods      : create_menu_bar redefinition
                 , create_horizontal_scroll_bar redefinition
                 , create_vertical_scroll_bar redefinition
                 .
endclass.
class firefox_widget_factory implementation.
  method create_menu_bar.
    create object menu type firefox_menu_bar.
  endmethod.
  method create_horizontal_scroll_bar.
    create object scroller type firefox_horizontal_scroll_bar.
  endmethod.
  method create_vertical_scroll_bar.
    create object scroller type firefox_vertical_scroll_bar.
  endmethod.
endclass.

class opera_widget_factory definition
                             inheriting from browser_widget_factory.
  public section.
    methods      : create_menu_bar redefinition
                 , create_horizontal_scroll_bar redefinition
                 , create_vertical_scroll_bar redefinition
                 .
endclass.
class opera_widget_factory implementation.
  method create_menu_bar.
    create object menu type opera_menu_bar.
  endmethod.
  method create_horizontal_scroll_bar.
    create object scroller type opera_horizontal_scroll_bar.
  endmethod.
  method create_vertical_scroll_bar.
    create object scroller type opera_vertical_scroll_bar.
  endmethod.
endclass.

Listing 14-13 shows the definition for a browser manager class making use of the preceding classes and playing the role of the Client participant.

Listing 14-13. Definition of Class browser_manager

class browser_manager definition.
  public section.
    methods      : constructor
                 , hover_over_menu_item
                 , left_click_on_menu_item
                 , right_click_on_menu_item
                 , scroll_back
                 , scroll_forward
                 , scroll_left
                 , scroll_right
                 .
  private section.
    data         : menu_bar         type ref to menu_bar
                 , horizontal_scroll_bar
                                    type ref
                                      to horizontal_scroll_bar
                 , vertical_scroll_bar
                                    type ref
                                      to vertical_scroll_bar
                 , widget_factory   type ref
                                      to browser_widget_factory
                 .
    methods      : get_widget_factory
                     exporting widget_factory
                       type ref to browser_widget_factory
                 .
endclass.

The definition of the browser manager includes some public methods for responding to user actions as well as a public constructor. Its private members include references to a menu bar, a horizontal scroll bar, and a vertical scroll bar, in addition to a reference to the browser widget factory that will create these browser widgets, each of which correlates to the aggregation relationship lines of Figure 14-4 leading to the client entity from the menuBar, scrollbar, and browserWidgetFactory abstract entities. Notice that the data definitions for the menu bar and horizontal and vertical scroll bars are references to abstract classes, enabling the client to invoke menu clicking and scrolling for the browser without ever having to know the specific type of browser for which these widgets are associated. Notice also that the data definition for the widget factory is a reference to an abstract class, enabling the client to invoke methods of the factory to create menu bars and scroll bars also without ever having to know the specific type of browser for which this factory makes widgets.

Listing 14-14 shows the implementation of the browser manager class.

Listing 14-14. Implementation of Class browser_manager

class browser_manager implementation.
  method constructor.
    " create instance of abstract factory:
    call method me->get_widget_factory
      importing widget_factory    = me->widget_factory.
    " use abstract factory to create 1 menu bar and 2 scroll bars:
    call method me->widget_factory->create_menu_bar
      importing menu              = me->menu_bar.
    call method me->widget_factory->create_horizontal_scroll_bar

      importing scroller          = me->horizontal_scroll_bar.
    call method me->widget_factory->create_vertical_scroll_bar

      importing scroller          = me->vertical_scroll_bar.
  endclass.
  method get_widget_factory.
    data         : widget_manufacturer type seoclsname.
    determine type of browser.
    case type of browser.
      when 'firefox'.
         widget_manufacturer = 'FIREFOX_WIDGET_FACTORY'.
      when 'opera'.
         widget_manufacturer = 'OPERA_WIDGET_FACTORY'.
      when others.
        o
        o
    endcase.
    create object widget_factory
           type (widget_manufacturer).
  endmethod.
  method hover_over_menu_item.
    call method menu_bar->hover_over_menu_item.
  endmethod.
  method left_click_on_menu_item.
    call method menu_bar->left_click_on_menu_item.
  endmethod.
  method right_click_on_menu_item.
    call method menu_bar->right_click_on_menu_item.
  endmethod.
  method scroll_back.
    call method vertical_scroll_bar->scroll_back.
  endmethod.
  method scroll_forward.
    call method vertical_scroll_bar->scroll_forward.
  endmethod.
  method scroll_left.
    call method horizontal_scroll_bar->scroll_left.
  endmethod.
  method scroll_right.
    call method horizontal_scroll_bar->scroll_right.
  endmethod.
endclass.

The public constructor invokes the private method get_widget_factory, which will instantiate a browser widget factory based on the active browser. Once the browser widget factory has been instantiated, it is invoked by the constructor to create a menu bar and two scroll bars. The remaining methods react to subsequent user actions, such as clicking a menu item and scrolling, each one of which invokes a corresponding method of the menu bar or scroll bar widget instance created by the browser widget factory.

Finally, Listing 14-15 shows an entity that creates and uses the instance of the browser manager class.

Listing 14-15. Entity Creating and Using an Instance of Class browser_manager

class screen_manager definition abstract final.
  public section.
    class-methods: class_constructor
                 , scroll_right
                   o
                   o
                 .
  private section.
                   o
                   o
    class_data   : internet_browser type ref to browser_manager.
endclass.
class screen_manager implementation.
  method class_constructor.
    create object internet_browser.
  endmethod.

  method scroll_right.
    call method internet_browser->scroll_right.
  endmethod.
    o
    o
endclass.

Notice in all of the preceding ABAP code the absence of conditional logic with the exception of the case statement in the get_widget_factory of class browser_manager, where the determination is made for the type of active browser so the correct type of concrete widget factory can be identified. Once identified and an instance of a browser widget factory is created, we no longer need to check the type of browser for which widgets need to be made nor for the type of browser the user actions correspond to, all of which is implicit based upon the concrete widget factory instantiated and all the widget instances this factory will produce.

Summary

In this chapter, we learned about the multiple variations of the Factory design pattern, and that all variations are dedicated to the task of creating instances of classes. The Simple Factory relies on private instantiability to restrict solely to the class itself the ability to create instances of the class, while the Factory Method design pattern relies on class inheritance for instance creation, and the Abstract Factory design pattern relies on class composition to facilitate creating instances. Another significant difference between them is that the Simple Factory facilitates creating instances of the same class, the Factory Method facilitates creating instances of other classes (where the class to be created is controlled by a subclass), and the Abstract Factory facilitates creating instances of other classes that all have a family relationship.

Factory Exercises

Refer to Chapter 11 of the functional and technical requirements documentation (see Appendix B) for the accompanying ABAP exercise programs associated with this chapter. Take a break from reading the book at this point to reinforce what you have read by changing and executing the corresponding exercise programs. The exercise programs associated with this chapter are those in the 304 series: ZOOT304A through ZOOT304D.