Skip to Content
Technical Articles
Author's profile photo Vicenç Xavier Lozano

OOPen question: to save time or to save memory?


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.


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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo David Joseph
      David Joseph

      This question very quickly morphed into another question in my mind as I read through your blog. Should you follow a stateless design or stateless design. The answer also can be derived from the results of this comparison.

      You will store the retrieved information if it provides any benefit to future processing like validation, mapping, or even for logging (storing the old and new values to be used in change documents) etc...

      On the other hand, if you are simply returning the current state of something, the method can simply fetch the fresh values (out of the BAPI as in your scenario) and pass it on.

      So maybe in your proposal, you can split the instruction on the basis of design. Prefer no attribute design when the process requires no benefit in future transactions (stateless) or the other way with storing data in attributes to improve the flow of your application.


      Author's profile photo Vicenç Xavier Lozano
      Vicenç Xavier Lozano
      Blog Post Author

      I love it!