Padrão de especificação e princípio fechado aberto

5

Estou estudando os princípios do SOLID e estou tendo alguns problemas para lidar com o Padrão de Especificação e o código aberto / princípio fechado.

O fato é que o padrão de especificação introduzido por Eric Evans e Martin Fowlers cria alguma abstração e uma maneira realmente aberta de gerenciar regras de negócios.

Mas eu queria saber se realmente foi baseado no princípio Aberto / Fechado.

O fato é que, quando precisamos de uma nova regra, podemos estendê-la de nossa classe de especificação pai. Então, é aberto em extensão, que é um bom ponto do ponto de vista do SOLID.

Por outro lado, o padrão de especificação é baseado na combinação de regras, portanto, temos que modificar o código de regras ou, pelo menos, o código de regra pai. Desta forma, estamos abertos em modificações em uma classe que, em minha opinião, não deve ser modificada.

Eu provavelmente não entendi nada nesse processo.

Alguém pode me explicar:

  • Como (se for o caso) o padrão de especificação respeita o princípio OC?
  • Existe uma alternativa para esse padrão?
por mfrachet 24.08.2016 / 19:18
fonte

2 respostas

2

Os princípios do SOLID são mais úteis para escrever componentes de software reutilizáveis , como bibliotecas ou frameworks, e a idéia do OCP é criá-los de maneira a evitar alterações desnecessárias depois, mesmo quando os requisitos são estendidos ou mudou.

O Padrão de Especificação, até onde eu entendi, é sobre a criação de regras de negócios complexas a partir de pequenos blocos de regras . Portanto, para este cenário, as partes reutilizáveis são os blocos de construção de regras, não as regras de negócios agregadas em si. E, como você mencionou por si mesmo, o padrão de especificação fornece um design em que o conjunto de blocos de regras pode ser facilmente estendido sem qualquer alteração em outros blocos de construção ou infraestrutura, portanto, ele segue o OCP.

No entanto, quando uma regra de negócios complexa é alterada, você obviamente precisa alterar algo em seu sistema, e essa é obviamente a parte em que a regra de negócios é definida. Não há um padrão que possa impedir completamente a necessidade de mudanças no sistema quando as regras mudam.

A única coisa que você pode fazer aqui é projetar o sistema de forma que a parte que precisa ser alterada não esteja enterrada em algum lugar no interior do código, mas movida para um local onde possa ser editada alterando uma configuração separada em vez de. Isso permite mudar a responsabilidade de mudar em algum grau dos desenvolvedores para outra pessoa, por exemplo, para o usuário do seu sistema. Assim, os usuários podem criar ou alterar regras de negócios complexas a partir dos blocos de construção que você fornece para eles.

A abordagem típica para isso é criar um DSL para isso, onde os elementos DSL se referem às regras elementares e os operadores que você definiu usando o padrão de especificação. O código DSL, em seguida, pode ser armazenado em um arquivo de configuração que é mantido ou estendido por alguém que não é o desenvolvedor do sistema, talvez um usuário ou um "usuário avançado".

    
por 27.08.2016 / 11:15
fonte
2

Em um dos comentários, fui solicitado a fornecer alguns exemplos de idiomas baseados em regras. Os links aqui listam alguns idiomas. Eu criei uma linguagem baseada em regra personalizada no passado, específica para o setor de controle de processo. Você pode criar seu próprio idioma ou usar um existente, mas é útil entender vários algoritmos se você criar o seu próprio:

Para mim, o mais interessante sobre alguns sistemas de regras, do ponto de vista do usuário final, é que eles retornam automaticamente o estado de volta a um padrão quando nenhuma regra se aplica.

    
por 31.08.2016 / 03:37
fonte