Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

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

Former Member
0 Likes
554

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-&gt;get_contract_positions() which means my impl and my caching-layer gets more complex
    1. 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( ).

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-&gt;get_contract_positions() which means my impl and my caching-layer gets more complex
    1. 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( ).

1 REPLY 1
Read only

Former Member
0 Likes
506

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.