problem with SEO_METHOD_GET_SOURCE

[Former Member]

i use the SEO_METHOD_GET_SOURCE function to get the source code of method.

now i want to scan the source code to find the violation of the law of demeter.

please give me some example about the SEO_METHOD_GET_SOURCE.

thans

best regards

yinxiao

[Former Member]

Hi,

Go through this link. Let me know it will helpful to you or not.

http://scn.sap.com/thread/1496837

Thanks,

Sanjeeb.

[Former Member]

thanks for replay.

i use SEO_METHOD_GET_SOURCE to get the method code.

but it come a problem.

This function can the method, which is redefined get.

[Ruediger_Plantiko]

Hi Yinxiao,

I have no solution but I want to say that I find this an interesting problem: To compute violations of the Law of Demeter in ABAP methods.

I looked in the "Code metric" section of the Code Inspector (transaction SCI), but there is no check for this, at least in my release (SAP_BASIS 702).

Maybe this check would be a good extension of the Code Inspector's code metrics in a forthcoming release?

It will probably difficult to write such a detector using the statement "SCAN ABAP-SOURCE ... " only, since on the token level, there are so many different ways to write down a method call. Some higher level of syntax tree would simplify the task. But I don't know whether there is an ABAP call to obtain an AST ...

Just "thinking loudly"...

Regards,

Rüdiger

[Former Member]

thanks for your replay.

i'm glad to hear that you are interesting this problem. i find some good tools in Java or C++ that detect the violation of Low. but nothing in ABAP. The Low is very important  design guideline for OO program. since we have the ABAP OO, so i think maybe do something in ABAP language.

i am a new guy in ABAP and looking for ur Help

my idea:

1, read all the method. (with SEO_METHOD_GET_SOURCE , maybe do it as a preprocessor )

2, find out the calling method. (do String operation, find " ->" )

3, detect the violation.

4, show result.

Regards

Yinxiao

[Ruediger_Plantiko]

Hi Yinxiao,

there are some tools that may help you with this task. Namely, CL_ABAP_CLASSDESCR is a reflection object which gives you details on all the properties of a class.

Important for the LoD is the information:

- Global attributes of the class (contained in internal table ATTRIBUTES)

- The parameters of the method (component parameters of lines of attribute METHODS).

Also helpful can be the built-in scanner, available with the ABAP command "SCAN ABAP-SOURCE" (see my description here: http://wiki.sdn.sap.com/wiki/display/stage/Tool+to+generate+a+class+implementation+from+its+definiti... )

I have made you a little start with my test program ZZ_CHECK_DEMETER_LAW. You can copy it from http://pastebin.com/25ErsYbf It should be self-contained.

Currently, the program detects the "train wreck catastrophes" like

a->b->c( ).

But it is still a demeter law violation, if such a statement is divided into two statements:

data x.

x = a->b.

x->c( ).

To detect this kind of LoD violations, a deeper level of code analysis would be necessary. But the tools of the class LCL_CHECK_DEMETER may serve you for implementing this kind of analysis.

Regards,

Rüdiger

[Clemenss]

Yinxiao Liang Ni Hao,

I don't know how the checks work in java or C++. But there will be something more in ABAP than find -> (or =>) to detect method calls: To detect violations you need some more context information about all methods of the same class that may be called without violations and all objects (and their respective) methods made available via interface of the function.

Still: This would be a great project!

Regards

Clemens

[Former Member]

Thanks again.

ur answer is very helpful. The program is a great job.

And Now i think i should focus on learning ABAP.

ur help is highly appreciated

Regards

Yinxiao

[Former Member]

Clemens Li Ni Hao，

thanks for ur replay.

i will make a table for each class. the context information will in stored in it. it easy to find all methods of the same class, but hard to all objects (and their respective) methods.

I will continue work on this problem and look forward to get ur further help.

Xie xie

Regards

Yinxiao

[Ruediger_Plantiko]

Yinxiao,

the problem is indeed very difficult. A deep syntactical analysis of the code is required to get Demeter Law violations. It requires deep insight in the ABAP compiler.

Maybe somebody from the ABAP language group can help you out with this. For me, it would be too much work to solve it completely, since I would have to re-invent what the compiler guys in Walldorf already have implemented (although mostly not in ABAP, but in the ABAP kernel, but maybe there are ways to access their code).

You need to know

• the global attributes of the class which are of type object reference (OK, that's relatively simple, see above, CL_ABAP_CLASSDESCR).
• the interface parameters of the method which are of type object reference (similarly)
• the components of structures (attributes or interface parameters) which are of type object reference
• the local variables which are of type object reference
• the components of local structures which are of type object reference
• ... many more special cases I don't think about right now.

An object type reference is not always defined in the form

data: lo_server type ref to if_http_server.

But the type may be declared in a type pool or  even in the DDIC:

types: ty_server type ref to if_http_server.

Then, in the code that you analyse, you only see this statement:

data: lo_server type ty_server.

This means that you have find out: this type is of type ref to object, which cannot be deduced from the code you are actually scanning. You'll have to resolve the type and get its description...

Also, it can be referred to another variable which is visible in the current scope:

data: lo_server like io_server.

You have to re-trace this "like" mechanism, to go to the root type that is actually used.

That's only one aspect of the problem.

Another problem is with "local object creation". Demeter Law talks about local instances which are created in the method (for those local instances, Demeter Law allows the access to teir attributes and methods).

How to determine automatically that an object reference is created in the method?

Do you think that it will always be instantiated with a "create object" statement?

data: lo_dates type ref to zcl_date_helper.

create object lo_dates.

That's not the only way to get instances. There may be a factory method

data: lo_helper type ref to zcl_date_helper.

lo_dates = zcl_date_helper=>create( ).

or

lo_dates ?= zcl_factory=>get_object( 'dates' ).

But how do you know automatically that the method "create" is a method which creates objects? By its name? Surely not. On the other hand, a static method call could do any other task as well. Even the fact that it returns an object instance doesn't prove that it's an object factory!

How do the Java and C++ tools work around this?

Regards,

Rüdiger

[Former Member]

Lod in ABAP

method M of class C can call:

1. other methods in class C.
2. methods on attributes of class C.
3. methods on those parameters of  method M.
4. method on the local data, which is created in M.

there are four ways to call a method.(when there are other ways, please let me know)

1.call method

2.->

3.=>

4.method name

when we use "call method", "->" and "=>" are also used.

"=>" it is for static method.

so my concern is all about "->".

scan "->" in code we get method caller and method.

in order to find violation, check the method caller.

method caller is:

ME.

attributes of class C.

parameters of method M.

local object. (by scan "->" build a data dictionary, keywords "data")

otherwise, there is a violation.

about the data dictionary, we can by the data definition to build it.

in this project i focus on the method caller, not on the method or which data type of the method caller. The compile can solve the error in method.

this is my original idea, please help me to make it better.

thanks again, you help me a lot.

regards

Yinxiao

[Ruediger_Plantiko]

Hello Yinxiao,

I think your plan will give you a 95% solution. Some more complex cases are not covered. But it can be helpful to have such a rule, even if it is not a 100% solution. The remaining 5% can become arbitrarily complex.

By the way, why are you disregarding static method calls? I think

a=>b->c( )

or, equivalently:

lo_b = a=>b.

lo_b->c( )

is a Demeter rule violation as well...