Skip to Content
-3

TYPES or DATA? Which one is better?

Apr 12 at 07:05 AM

152

avatar image
********* Using TYPES *************
TYPES: BEGIN OF lts_university,
       INCLUDE TYPE zcl_s20_universit_mpc=>ts_college.
       TYPES : departments TYPE ztts20_dept,
       * types: departments type zcl_s20_universit_mpc=>tt_department,
       * types: departments type table of zTS20_DEPT,
END OF lts_university.

DATA lt_university TYPE TABLE OF lts_university.
DATA ls_university TYPE lts_university.

********* Using DATA **************
DATA: BEGIN OF lss_university,
        INCLUDE TYPE zcl_s20_universit_mpc=>ts_college.
        DATA: departments TYPE zcl_s20_universit_mpc=>tt_department,
        * DATA: departments type table of zTS20_DEPT,
END OF lss_university.

DATA ltt_university LIKE TABLE OF lss_university.
***DATA lss_university LIKE ltss_university. 


My Observations :

1) In case of TYPES lts_university will have no memory allocated to it.
In case of DATA, we will already have a work area.
2) In case of TYPES, I am not able to use
a) departments type zcl_s20_universit_mpc=>tt_department
b) departments type table of zTS20_DEPT ( zTS20 is a database table )
In case of DATA, I am able to use both a) and b)

******************************************************************

Considering zcl_s20_universit_mpc=>tt_department and ztts20_dept, both to be table types with same structure fields, which one among TYPES or DATA one should use? Which one is better and why?

Regards,
Gopa

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

5 Answers

Matthew Billingham
Apr 12 at 08:43 AM
4

Never use:

DATA:BEGIN OF

always use types. Why? You never know when you're going to pass data as a parameter. If you've defined the type, it's easy.

You question is deficient. You've declared that:

In case of TYPES, I am not able to use
a) departments type zcl_s20_universit_mpc=>tt_department
b) departments type table of zTS20_DEPT ( zTS20 is a database table )

But you've not said why or what error message you get. It may simply be that you've not got the syntax correct. (I.e. problem lies between keyboard and chair, not with ABAP ;-) ).

Show 4 Share
10 |10000 characters needed characters left characters exceeded

Error messages:
a) departments type zcl_s20_universit_mpc=>tt_department
"TT_DEPARTMENT" is a generic type. Use of this type is only possible for typing field symbols and formal parameters. -

b) departments type table of zTS20_DEPT ( zTS20 is a database table )
You cannot use generic type definitions within structures.

0

And there's your answer. Don't use a generic type, use one that's fully defined.

As a general rule of good practice the type of an object should be as tightly defined as possible. Only use generic types where absolutely necessary. With tightly defined types, you can pick up typing errors in syntax checks, when it's cheap, not at runtime where it gets progressively more expensive.

Here's a discussion of type safety. It's to do with FORMs, rather than OO programming, but the principles are the same.

1

Hi Matthew,

I went through your interesting type safety blog w.r.t. FORMS.
I have added some more lines of code.
I know that TYPE is better than LIKE for better performance.
Here I can point to the data object itself using DATA: BEGIN OF... passing DATA as a parameter.

I might not have understood you properly.
If you could guide me w.r.t. the same example, it would be really helpful.

********* Using TYPES *************
TYPES: BEGIN OF lts_university,
       INCLUDE TYPE zcl_s20_universit_mpc=>ts_college.
       TYPES : departments TYPE ztts20_dept,
       * types: departments type zcl_s20_universit_mpc=>tt_department,
       * types: departments type table of zTS20_DEPT,
END OF lts_university.

DATA lt_university TYPE TABLE OF lts_university.
DATA ls_university TYPE lts_university.

********* Using DATA **************
DATA: BEGIN OF lss_university,
        INCLUDE TYPE zcl_s20_universit_mpc=>ts_college.
        DATA: departments TYPE zcl_s20_universit_mpc=>tt_department,
        * DATA: departments type table of zTS20_DEPT,
END OF lss_university.

DATA ltt_university LIKE TABLE OF lss_university.
DATA lss_university2 LIKE lss_university.

* Filling lss_university.
PERFORM test1 USING lss_university.
* Filling lss_university2.
PERFORM test2 USING lss_university2.

*&---------------------------------------------------------------------*
*& Form test1
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM test1 USING iss_university LIKE lss_university.
ENDFORM. "test

*&---------------------------------------------------------------------*
*& Form test2
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM test2 USING iss_university LIKE lss_university.
ENDFORM.   

0

You shouldn't be using FORMs in the first place - they're obsolete.

TYPE is not "for better performance.". You use LIKE, TYPE where appropriate to make the meaning of what you're doing as clear as possible.

Sorry - I don't have the time for personal mentoring. I've already given you good hints. It's up to you to apply them.

2
Horst Keller
Apr 12 at 08:28 AM
3
Show 1 Share
10 |10000 characters needed characters left characters exceeded

Thank you.

0
Stefan Seeburger 6 days ago
1

you cant write "like"-statement in Abap-OO

So time is saved when going with types.

Types cant store Data. so when reading Code, you can read it faster when there are alot global types than when there are alot of global data-structures

regards

Share
10 |10000 characters needed characters left characters exceeded
Sandra Rossi Apr 13 at 05:32 AM
-3

It's fun to see answers like Never or Always do this because of a list of good reasons (even the rule given in the guidelines of the ABAP documentation), because this doesn't prevent an unlisted case to exist that makes that rule fail (as we say in French: "there is always an exception to a rule").

For choosing between a "bound data type" or a "standalone data type", you should apply those 2 rules: YAGNI (you ain't gonna need it) and DRY (don't repeat yourself). I don't know the name of the principle of always selecting one way when there are two ways (kind of "reduce the knowledge required to the minimum"), which we use a lot in my consulting company because it's said that even non-developers should be able to understand and modify the code (maybe it's a branch of KISS principle).

So, if you need to store data in a private structure used once, for instance for clearing all fields at a time, or define a private elementary variable of 2 characters for some reasons, I don't see the reason why you couldn't use a bound data type (YAGNI/KISS principles). Probably there would be better examples...

If you have to use a public attribute, or a private data type used several times, then okay, define a standalone data type.

Show 2 Share
10 |10000 characters needed characters left characters exceeded

YAGNI does not apply to coding style; it is rather concerned with coding for functionality that is not required at this time.

Regarding prescriptive direction, the thing is, when we've got so many newbies asking basic questions, and many who will go onto other things after a couple of years and never become experienced, it is far better to give them rules that generally improve the code base. For the inexperienced, it's better to say:

  • ALWAYS do this
  • NEVER do this.

If the OP ALWAYS declares his types before using and NEVER uses DATA: BEGIN, he won't go far wrong. When he or she has been coding for five or more years, and has gained some competence, then we can go into the exceptions.

  • ALWAYS break the rules when your experience tells you it is necessary.

My experience is that I've so frequently had to switch from a DATA: BEGIN to declaring the types that I think it is quicker and more efficient to just use TYPES to start with. Even if You Aint Gonna ...er... Use It more than once. It doesn't cause any harm and doesn't detract. I would maintain it doesn't change complexity, and therefore KISS doesn't apply either.

DATA: BEGIN to me is an ugly short-cut akin to tables with header lines. I'd be glad to see it made obsolete.

It's like the OO paradigm of always coding to an interface; it seems like overkill at first. But when you start having to refactor (or you start using Test Driven Development!), you bless the programmer who stuck to it.

2
Matthew Billingham

Well ... I must admit that I agree to all of your arguments. Thanks for the clarification :)

1
Tomas Buryanek Apr 12 at 07:23 AM
0

You can use table types in TYPES definitions.

Check this part of ABAP documentation for table genericness:

https://help.sap.com/http.svc/rc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abaptypes_keydef.htm

Share
10 |10000 characters needed characters left characters exceeded