Skip to Content
Introduction

There were many discussions on design patterns in OO ABAP and wether they’re worth the learning effort of or not. I believe yes,
but I won’t discuss it here.
I’ll rather give a live example and try to describe here how I have implemented the Decorator pattern in OO ABAP.
I’ll handle here a simple action of providing lookup data for a structure or an
internal table in an unusual, reusable and chainable, way.

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:

 

…and that you filled it’s rows with only WERKS (plant code) fields:

t_itab


      <font face=”Tahoma” style=”font-size: 8pt”>WERKS</font>


      <font face=”Tahoma” style=”font-size: 8pt”>PLANT_NAME</font>

1030  
1130  
1330  
2030  

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

t_itab


      <font face=”Tahoma” style=”font-size: 8pt”>WERKS</font>


      <font face=”Tahoma” style=”font-size: 8pt”>PLANT_NAME</font>
First you need variable declarations. Although any component can be final as long as it’s the last in a chain,
I created here a dummy final to show flexibility. +Dummy
final+ is generic and doesn’t do anything but abstract all the others at the moment of usage.

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:

Usage:

Here you’re fetching data and filling your itab‘s lookup fields:




I won’t explain the attributes here, since they’re all initiated by the CONSTRUCTOR and I’ll explain them as it’s parameters.
I’ll only say that this NEXT_DECORATOR has a confusing name – it would be PREVIOUS_DECORATOR if I didn’t
experience semantic confusion at that time. First I
believed it was next, and later realized that the name previous
better matches the instantiation sequence. I corrected the public interface, but
forgot the attribute. And it’s hard to correct it now because I had to leave the company, I’m not on the original system
and modification assistant harrasses me. Sorry, I hope you’ll still be able to
catch it.

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. GET_FIELDS has only one changing parameter:

Name

Type

Description

CH_STRUC ANY itab line with fields, say
LIFNR, VENDOR_NAME etc. This method returns them filled

    1. CONSTRUCTOR has only importing parameters:

Name

Type

DescriptionMany thanks to Thomas Jung whose hints helped me to make this weblog look better than plain text.

To report this post you need to login first.

16 Comments

You must be Logged on to comment or reply to a post.

  1. Scott Barden
    Hi Igor,

    I thought the weblog was good.  It is interesting to see design patterns applied to ABAP.

    However, I did have difficulty following the text.  Perhaps the ending needs to be more at the beginning to show what you’re trying to achieve???

    Cheers,
    Scott

    (0) 
  2. Phil Martin
    Sounds fantastic – good job with this blog – I just wish I had a good enough understanding of OO to put it into practice!
    (0) 
    1. Igor Barbaric Post author
      Hi, Phil!
      I’m glad that you liked my weblog. Thanks for your comment! I was also pretty much ignorant to objects when I started to play with patterns. After reading an excellent book, in 6 months I made an application that I was extremely happy with, and users and my boss too. As a by-product I made a framework for building applications that this component is just a part of. I plan on posting a series of weblogs on the whole thing. I’ll also give an abstract session on it on the SDN Meet Labs Waldorf/Rot, April 19, 2005.
      As opposed to some rather pesimistic experts claiming that one has to master design patterns to be profitable with them (or otherwise just do damage), authors of the book write in the preface that (I quote) “students who learned object-oriented design concurrently with design patterns learned object-oriented design faster than those studying just object-oriented design.”. It was exactly my situation and it turned out to be true for me. This book does this: introduces object paradigm along with design patterns to a beginner. I can see that your situation is similar, and I can recommend the book.
      It’s Shalloway/Trott’s “Design Patterns Explained”.
      Have fun!
      Igor
      (0) 
  3. Igor Barbaric Post author
    Hi!
    I wonder has anyone actually tried to implement the itab lookup functionality from my weblog? Or does it look too complicated to give it a try, or something else? Were there any successes?
    I’d appreciate any feedback. Thanks!
    (0) 
    1. Brad Williams
      Hi Igor,

      I would have to concurr with Scott.  Its a little bit difficult to grasp what you are trying to say.

      As I don’t have time to actually try out your example at the moment, and I find it difficult to see the point, my inclination is to file this away as a reference and come back to it if I have a specific requirement.

      Not saying I have mastered the art of blogging, but the easier they are to read, the better your message will come across.

      Just my 2 cents worth.

      Cheers,

      Brad

      (0) 
    2. Brad Williams
      Sorry, forgot to add.

      I find this area very interesting (algorithms/patterns) and would be keen to see more blogs/discussion about it.

      Cheers,

      Brad

      (0) 
    3. Brad Williams
      Sorry, forgot to add.

      I find this area very interesting (algorithms/patterns) and would be keen to see more blogs/discussion about it.

      Cheers,

      Brad

      (0) 
      1. Igor Barbaric Post author
        Hi, Brad!
        I am really sorry that this is so hard to read. I’ll try to renew the blog to make it more simple and clear.
        Thanks a lot for your feedback!
        Igor
        (0) 
      2. Igor Barbaric Post author
        Hi, Brad!
        I am really sorry that this is so hard to read. I’ll try to renew the blog to make it more simple and clear.
        Thanks a lot for your feedback!
        Igor
        (0) 
  4. Ravi Andela
    Hi Igor,

    It may be too late to respond to your blog, But I feel Better Late, than Never…

    Thank you somuch for such a wonderful Blog…

    You have ignited my mind to learn Design Patterns. I really afraid of learning the Objected Oriented Design, thats why I have opted for ABAP than Java (thinking that I need not learn OOPs… Later I found the oops.. OOPs is so easy and more practical than procedural).. Then, I slowly started learning OOPs.

    Truly, you ignited my mind to think about Design Patterns..

    Coming to the point, I have a doubt (It may seems silly to you, But I can’t hold that)

    In the above example we were talking about the reusuability.. My question is

    if I use local classes like you used in Plant Name decorator, Its not reusuable right? (Correct me if I was wrong).

    To make the reusuability work we need to define the global classes for each context (like one for vendor, other for customer etc…) Is  that true?..

    Please clarify..

    Regards..

    Ravi

    (0) 
    1. Igor Barbaric Post author
      Hi, Ravi!
      Thanks for your comment! I was pleasantly surprised that to learn that someone is actually reading such old weblogs, and moreover, find them useful. I really believe that OOP is great and worth learning. Don’t be afraid! Once you start, the big OO puzzle reveals itself as a very natural and intuitive thing, far more intuitive than procedural programming, in my opinion.
      Now the answer to your question: you are right – the components in local program are NOT reusable. The point of the Decorator stuff from my blog is to have choice: for things that you’ll need in more programs, you make them global. But for one-time program-specific stuff, you can have them local. The only thing that MUST be global if you want this choice, is the superclass of decorators.
      However, for simplicity reason of the blog, I made them all local.
      There’s a functionality that you can try:
      Go to SE24 and then from menu: “Object Type -> Import -> Local Classes in Program”. This way you can instantly import your LCL local program classes into ZCL global classes.
      Good luck!
      Igor
      (0) 
  5. Raghunandan Vasudevarao
    Hello Igor,

    thank you for the wonderful post . I am in the process of discovering the design patterns and trying to apply them in SAP. Your post has helped me to gain further knowledge and confidence on the subject.

    Keep blogging !
    Raghu V

    (0) 

Leave a Reply