Aqui estão meus comentários convertidos em uma resposta.
-
1) É realmente necessária a interface para o que estou fazendo aqui, especialmente dado que é muito improvável que haja testes unitários para a lógica? A razão principal pela qual a criei é que parece ser a forma recomendada para classes/métodos públicos.
Não abstrairia se não houver motivo para isso. As recomendações existem apenas por boas razões e não acredito que se aplique ao seu caso.
-
2) Faz sentido o nome das diferentes entidades?
Se você tiver uma boa razão para usar uma interface, renomearia DAO para DB (suponho que DB seja mais conhecido que DAO), e a instância também deveria manter DB: db_zparameters. Nota: Não sou fã da notação húngara prefixada.
-
3) Como fazer com que o processo chamador saiba que é possível que não seja encontrada nenhuma entrada em RETURN_VALUE2 em um método funcional que apenas retorna exatamente um valor, neste caso o conteúdo de VALUE2? No momento, resolvo isso verificando se VALUE2 está preenchido, mas não tenho certeza se essa é a melhor/maneira correta de fazer isso.
Para retornar a informação encontrada/não encontrada, depende de você.
a) O uso do valor inicial não me incomoda, acompanhado de um comentário.
b) O uso de uma exceção também poderia ser válido.
c) O uso de uma referência, para retornar algum dado ou NULL significando não encontrado em seu caso.
Definição:
METHODS
return_value2
IMPORTING
i_zparameters TYPE zparameters
RETURNING
VALUE(result) TYPE REF TO zparameters-value2.
Implementação:
METHOD zif_table_zparameters_dao~return_value2.
SELECT SINGLE value2
FROM zparameters
INTO @DATA(value2)
WHERE modul EQ @i_zparameters-modul
AND z_program EQ @i_zparameters-z_program
AND field EQ @i_zparameters-field
AND value1 EQ @i_zparameters-value1.
IF sy-subrc = 0.
result = NEW #( value2 ).
ENDIF.
ENDMETHOD.
Uso:
DATA(value2) = int_zparameters->return_value2( VALUE
