Factory-Pattern in ABAP OO

[hendrik_brandes]

When you work with ABAP Objects you always need to create instances of classes. Even if you use "CREATE OBJECT" to create those instances, you probably faced with the problem, that it is not so comfortable as if you have a function for creating objects in the same way. Or, you have a complex logic to create each instance.

Background

For those cases, there is a design-pattern for creating instances. This pattern is called "Factory"-pattern. There is also a pattern called "factory-method", which is different, because it combines the creation and relationship of objects. Thanks to Naimesh Patel, who advise me of this point.

The factory-pattern is one of the most used design pattern. It creates object instances without exposing the concrete instantiation logic. The instantiated objects will be accessable through an interface, which encapsulate the concrete implementation to the users.

In the classical GoF-Pattern, the factory-pattern looks like this:

A client needs a product (a.k.a. "class") and asks a factory for a concrete instance by passing the neccessary parameters to it. The factory creates a class of a specific interface ( "Product" ) and gives the instance back to the client. The specific interface should also be an abstract class, but by using an interface you will have a much better support for the separations-of-concerns principle.

The ABAP-way of the factory pattern

Sure, it should be very simple, to transfer the underlying UML to a ABAP class structure. But, you have much more than just a OO-language: The SAP Netweaver AS gives you some nice featues - customizing with a maintenance dialog is one of them.

So, here is my approach for the ABAP OO-Factory:

As you can see, the factory use informations out of a customizing table and holds all created instances in a internal table. The rest ( Interface, Concrete Classes) are simple ABAP OO Elements. By the way: If you can be sure, that the instances should not be buffered so far, you do not need an internal table with all created instances. 

At least, the "create" Method is not so complex: 

The customizing table should look like this:

For your internal table in the factory, you should define a DDIC-Structure and Tabletype which includes the customizing information and a reference to the created instance.

One hint: Create a view on SEOCLASSTX and SEOMETAREL with the used interface as constant for "REFCLSNAME", use it as foreign-key and you get a DDIC-based check, if the used class implements the correct interface.

And last, but not least: you need a maintenance view, created by the maintenance view generator.

Why should you use a factory-pattern?

With the factory pattern you centralize the create of objects within your application. By using this approach, you can manage the instantiation of objects ( "Products" ) and separate the usage of the concrete implementation logic. 

Through interfaces you introduce the design principle "separation of concerns" and you give a contract for all users of your classes. By accepting this contract the users of your interface count on the correct implementation of the contract.

Additional, you get an overview about who implements your interface and where is it used - just look in the ABAP Workbench and expand the implementation tree of your interface:

Adding new aspects to your software

Another important thing, which I have not mentioned so far: You can build your factory in a way, that you can very easy introduce proxy-classes (another design pattern) which covers new aspects - for example: logging or authentication - without changing the underlying classes.

By using this, your user does not affect, that there is another implementation - the interface, and its underlying contract is stil fulfilled.

Conclusion

The factory-pattern is an important pattern for creating object instances within your own code. With this pattern, you can get a more manageable, extensible and customizable software.