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

Question

Hello,
this is a crosspost from Stackoverflow, 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( ).

Answer 1

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.