ABAP-OO: Another Layer (1 Interface) vs. extending N Interfaces?

Former Member — Mon, 26 May 2014 14:39:14 GMT

Hello,

this is a crosspost from <a href="http://stackoverflow.com/questions/23869744/another-layer-1-interface-vs-extending-n-interfaces" data-mce-href="http://stackoverflow.com/questions/23869744/another-layer-1-interface-vs-extending-n-interfaces">Stackoverflow</a>, any advice greatly appreciated.

I have an Data-Access Layer (SAP ABAP, but the language does not matter here) where I have 1 interface per entity/database-table, like

IF_DATA_CONTRACT_HEAD->get_contract_header( )
IF_DATA_OBJECT_CALC->get_object_calculations( )
40 more ...

These interfaces are implemented by the actual database-access class-impls and a generated caching-layer, which is pretty simple since the methods really do not have any parameters and just return "the relevant" data.In certain consumers however, I require a filtered access to the returned data, specifically I need to get the data of all interfaces (~50) constrained by contract-position.So, do you recommend to

A) extend all interfaces by an optional parameter like IF_DATA_CONTRACT_POSITION->get_contract_positions() which means my impl and my caching-layer gets more complex

B) should I create another interface IF_DATA_FILTER_CONTRACT_POSITION->set_contract_position_filter? for the sole purpose of explicitly filtering data-acesss

A) When extending every existing interface (the ~40-50 listed above) with the optional contract-position filter/constraint, the API is quite clean and would look like the following:

result = lo_data_object_calc->get_object_calculations( <FILTER> ).

As already mentioned, it would require me to extend every implementation, the data-access as well as the generated caching-layer.

B) With the explicit filter-interface IF_DATA_FILTER_CONTRACT_POSITION on the other hand, I would have yet another interface-layer around data-access and I could generate the uncoupled filtering impls. I would neither need to touch the actual data-access impl nor the generated cache-layer. However, the usage would be a little more clumsy, like

TRY. " down-cast from data-interface to filter-interface
 DATA lo_object_filter ?= lo_data_object_calc.
 lo_object_filter->set_contract_position_filter( <FILTER> ).
CATCH could_not_cast.
 RAISE i-need-a-filter-impl!
ENDTRY.
result = lo_data_object_calc->get_object_calculations( ).

Re: ABAP-OO: Another Layer (1 Interface) vs. extending N Interfaces?

Former Member — Tue, 05 Aug 2014 07:11:46 GMT

Update 05.08.2014: I decided to go with

C) create a seperate filter-object which explicitly filters the tables retrieved by e.g. get_object_calculations( ).

Reasoning: Separation of Concerns, explicit semantic of filtering, no need to update all interfaces or regenerate caching-layer.

topic Re: ABAP-OO: Another Layer (1 Interface) vs. extending N Interfaces? in Application Development and Automation Discussions

ABAP-OO: Another Layer (1 Interface) vs. extending N Interfaces?

Re: ABAP-OO: Another Layer (1 Interface) vs. extending N Interfaces?