OO ABAP and Design Patterns: itab lookup as Decorator pattern

This weblog contains the following subjects:

• The problem: internal table witout lookup data
• 
  
• Usual solution: tons of SELECTs and READs
• 
  
• Is this good?
• 
  
• The idea: reusable components
• 
  
• The Decorator pattern
• 
  
• Implementation - how it works?
• 
  
• Concrete components
• 
  
• Conclusion
• 
  

The problem: internal table without lookup data

Let's say that you have an internal table of plants, like this:

 <span>TYPES: BEGIN OF ty_data,         werks      TYPE werks_d, "plant code         plant_name TYPE name1,        END OF ty_data.DATA: t_itab TYPE TABLE OF ty_data.</span>

Now you need plant names to show them somewhere, for example, on a report.
You need:

Instantiation

You need, ofcourse, to create the objects. Let's assume the most complicated case: you have yourself an internal table
which needs all the lookup functionalities that you've created. You'll
instantiate a chain of decorators as follows:
<span>CREATE OBJECT: dec_plant_name,               dec_vendor      EXPORTING i_ref      = t_itab "for performance                                         i_prev_dec = dec_plant_name,               dec_customer    EXPORITNG i_ref      = t_itab "for performance                                         i_prev_dec = dec_vendor,               dec_comp_code   EXPORTING i_prev_dec = dec_customer,               dec_dummy_final EXPORTING i_prev_dec = dec_comp_code.</span>

Usage:

The methods: they almost do nothing except initiate attributes and call
corresponding methods of the previous decorator in chain. That's what the Decorator
pattern is about in the first place.

!https://weblogs.sdn.sap.com/weblogs/images/28520/AbsDecMethods.gif|height=218|width=290|src=https://weblogs.sdn.sap.com/weblogs/images/28520/AbsDecMethods.gif|border=0!

1. 
   
2. GET_FIELDS has only one changing parameter:
   
   

1. 
   
   
   
2. CONSTRUCTOR has only importing parameters: