Uma maneira de divulgar OperationsService
sobre o restante do sistema em relação a dados específicos é transmiti-los diretamente para uma base de necessidade: Você pode manter sua lógica de manipulação de configuração dentro de OperationsService
e adicionar um público AcceptOperations()
method em StorageService
que usa um objeto OperationsService
como um arg e invoca sua lógica de manipulação de configuração relevante, passando diretamente para ele quaisquer dados de configuração relevantes de propriedade privada.
Concretamente, você ainda pode ter GetConfigPropertyByNameAndDoSomeMagicWithIt()
como membro de OperationsService
, que chamaria AcceptOperations()
na instância StorageService
relevante e passaria this
como um argumento. AcceptOperations()
chamaria algum método ManipulateConfig()
concreto na instância OperationsService
dada a ele como um parâmetro, passando os dados de configuração internos para serem manipulados como argumentos para ManipulateConfig()
.
Esta proposta leva em parte algumas semelhanças com o padrão Padrão de visitante do OOP, excluindo o Double Dispatch idioma, mas mantendo o conceito de definir restritivamente quem pode visitar o que e definitivamente de acordo com a idéia original por trás do padrão que é realizar tal separação de responsabilidades tal que "... [fornece] a capacidade de adicionar novas operações para estruturas de objetos existentes sem modificar as estruturas. " Toda a idéia de tal padrão é ajudar a seguir o Princípio aberto-fechado , que é um dos princípios da SOLID, cuja manutenção você mencionou como uma preocupação sua para começar.