Object Oriented vs Context Oriented Programming

[Former Member]

A few weeks ago, I submitted a in which I tried to argue for a more object oriented approach to the structuring of WDP Components by using the javabean model as an abstraction layer for the WDP Context structure. My thinking on this matter has led me to another realization - an even more radical one at that, as it raises questions on a universally accepted feature of the Web Dynpro architecture:

<b>Is it really wise for a WDP Component to expose its Context to the world?</b>

Doesn't that go against the principle of encapsulation - one of the most important principles of object oriented theory? A component could and should be completely defined by the methods, properties and events it exposes to the outside world. Any client wishing to avail itself of the Component's services should be able to do so through this well defined interface - and all the rest should remain implementation details. That's how most component models I've worked with usually work.

SAP has done a decent job of designing WDP Components that have the expressive power to expose methods, properties and events. Why isn't this sufficient ? Can anyone here explain to me what advantage one gains by exposing the internal workings of the Component (ie its Context) thereby breaking the fundamental OO principal of encapsulation ? Isn't this "feature" of Web Dynpro actually encouraging bad OO development practices? Anyone from SAP's Web Dynpro Design team would care to take a shot at this one? Do they read these forums?

Romeo Guastaferri

[Former Member · Accepted solution]

Romeo,

Tell me how Context differs from public Properties (like in C# or JavaBean-like "methods" in Java)?

Personally, I see no difference -- Context is in fact grouped hierarchical properties of controller. No more no less.

Typically, contexts of custom controllers within single component are "visible" to each other, think about this feature as "friend" modifier in C++ or "package private" in Java. On other hand, when exposing Context to outer components you may restrict internal data via Interface Controller context with simpler / stricter structure that hides component's internals.

Probably you get granulation of WD programs wrong: the unit of reuse is component, not individual controllers within component. You may think about controllers as "helper classes" that works together and has "friendly" visibility. The sum of controllers is a component, in same sense as mixins in some OOP languages forms concrete class implementation via composition.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[Former Member · Accepted solution]

Hello Valery

I don't quite agree with you when you say "Context is in fact grouped hierarchical properties of controller". I would tend to say it's more like grouped hierarchical properties of the UI Elements and the Model objects that are used by the Controllers and Views. It is a structure designed for sharing data between Views and Controllers of a Web Dynpro Component. And as such, is an implementation level construct that should remain encapsulated at the Component level. Where I draw the line is in the practice of sharing Contexts between Components.

page 13 of <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/a048387a-0901-0010-13ac-87f9eb649381">The Structural Concepts of Web Dynpro Components</a> states that

<blockquote>

"...the Web Dynpro component is a reusable unit of code at the business process level, rather than the technical coding level."

</blockquote>

However, the Context is a technical Web Dynpro construct, not a business level concept. Why would you need to access the Context structure at the business level ? As a business client, I shouldn't be expected to master context manipulation api and have to navigate a structure to get at the information stored at the current lead selection. I should be able to easily query the component by invoking some

component.getSelectedEntity()

method. Let the component worry about navigating whatever internal representation it chooses to use (whether it be it Context API, JNDI, XML or whatever)... and just give me the information I need and ask for - in a format that makes sense to me, from a business perspective. I find this to be much more in tune with OO philosophy.

I shouldn't have to (and shouldn't be allowed to) dig in for myself in the data structure to extract the bits of information that I need. And it's for this reason that I expressed my opinion that exposing the Context at the Component level is not only unnecessary (properties, methods and events are perfectly adequate to publicly characterize a Component) but actually encourages bad OO programming practices.