Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
VXLozano
Active Contributor
0 Kudos

Intro


This post's origin is the doubt that appeared in my mind while I was writing some sort of "guidelines" proposal for my company.

Been an ancient reliq of the programming world, and having zero knowledge about how to develop properly, I am not able to decide which way to follow, so I decided to ask you (to do my work) instead.

Current state of my thinking process


(disclaimer: no drugs have been used, and no animals have been harmed during the ellaboration of this text and the referenced one, except by myself -my brain, basically-)

To restrict the use of public methods


I think it's a good thing to do it, allowing the publish of methods only for the get_ display_ print_ and/or send_ones.

Basically, the rule should say something like
A business class will have only public methods to get information or to provide instructions to the class (ie: get_header_data( ), get_calculated_speed( ), display( ) or update_number_of_ears( ) ).

Any other method/step will be private or protected (still wondering which and why... I'm still unable to differentiate both).

Worse than that


I'm planning to propose to forbid public attributes. Any attribute of the object will be obtained throughh a GET_ method. This will prevent the (ab)use of the attributes by programmers who don't care a sh... about the work of other programmers. Or, basically, to prevent them to modify data that can "travel" through the process steps via singleton (?) classes.

Not sure if I'm been clear enough (probably not). My idea is to have a singleton class "provider" that serves instances of the business object classes. Because that singleton will "travel" through the session memory, their instanced children will do too, and if a step changes the attribute of one of them "because", an anterior or posterior (to know wich one appeals more is a personal taste's question) step that uses that instance will get the wrong information.

Ok dude, what's your problem?


Oh, true, I'm (as always) lost in translation.

My problem is that another way that occurs (0 with header line) me to prevent that "attribute ruin" will be to NOT have attributes.

The what???


Think about it: with HANA (and even more in S4) we have all the data in the system's memory, so, why must I store the object's information in my instance if it's already in memory once I called it?

If my customer class has a get_header_data() method, and this method calls a read_header_data() one, which calls the BAPI_CUSTOMER_GETDETAIL, it's useful now to store that data in memory (in the "privotected" attribute header_data)?

Why not to call the BAPI every time I need customer info? That way I'll be sure to have the most udpated data and if another process changes the database, I'll have the "right" data and not the one that was right five seconds ago.

So...


Do I need to keep the retrieved info in memory to save processing time, or should I forget all I "know" and call the b..y BAPI as many times as needed?

 

What's your approach? Did you ever thought about that? Did I bored you enough with this post?

Feel free to expose your opinions, I will gladly use them if I like them, and I will be sure to NOT be thankful for them. Or will I?

 

PS: f...k, I know who I'd be mailing this question if he'd still alive... you are Tuly missed, mate.
2 Comments