O princípio da divisão de responsabilidades, também conhecido como coesão, defende que uma classe deve possuir apenas um, e apenas um, motivo para ser modificada. Se a classe possuir mais de um motivo para ser modificada então ela está mal definida.
A classe somente terá mais de um motivo para ser modificada se a mesma for responsável pelas ações às quais ela foi definida e por outras fora de seu escopo. No contexto do princípio da divisão de responsabilidades, responsabilidade é definida como razão para mudanças. Se for possível imaginar mais de um motivo para modificar a classe, logo esta classe possui mais de uma responsabilidade.
No exemplo a seguir foi definida uma interface “Modem” onde as funções declaradas parecem corretas dentro do contexto das funcionalidades que um modem deve exercer.
Ilustração 1 - Interface Modem
Porém, analisando detalhadamente a iliustração 1 é possível identificar que a classe possui duas responsabilidades: conexão e comunicação. As funções “Dial” e “Hangup” controlam a conexão e as funções “Send” e “Recv” controlam a comunicação.
Se os requisitos da aplicação mudassem de modo a afetar mais frequentemente as funções de conexão, o design demonstraria rigidez, um dos odores de decomposição do software. A aplicação seria rígida porque ao alterar algo na conexão seria necessário compilar e distribuir novamente toda a parte de comunicação sem necessidade alguma.
A ilustração 2 demonstra como ficaria o design ao separar as responsabilidades.
Ilustração 2 - Interface modem separada
Para separar as responsabilidades da interface modem de modo que a aplicação não sofra de rigidez, foi necessário aumentar a complexidade do sistema. Todavia deve-se tomar muito cuidado ao aplicar o princípio, pois se os requisitos da aplicação fossem tais que sempre alterariam ambas as responsabilidades, conexão e comunicação, o novo design seria incorreto devido ao fato de ter gerado complexidade desnecessária à aplicação, outro odor da decomposição do software. Portanto a aplicação do princípio de divisão de responsabilidades, ou outro qualquer, deve ser feito de modo cuidadoso e inteligente. Só se deve utilizá-los se o design estiver exalando algum dos odores de decomposição do software.
A classe somente terá mais de um motivo para ser modificada se a mesma for responsável pelas ações às quais ela foi definida e por outras fora de seu escopo. No contexto do princípio da divisão de responsabilidades, responsabilidade é definida como razão para mudanças. Se for possível imaginar mais de um motivo para modificar a classe, logo esta classe possui mais de uma responsabilidade.
No exemplo a seguir foi definida uma interface “Modem” onde as funções declaradas parecem corretas dentro do contexto das funcionalidades que um modem deve exercer.
Ilustração 1 - Interface Modem
Porém, analisando detalhadamente a iliustração 1 é possível identificar que a classe possui duas responsabilidades: conexão e comunicação. As funções “Dial” e “Hangup” controlam a conexão e as funções “Send” e “Recv” controlam a comunicação.
Se os requisitos da aplicação mudassem de modo a afetar mais frequentemente as funções de conexão, o design demonstraria rigidez, um dos odores de decomposição do software. A aplicação seria rígida porque ao alterar algo na conexão seria necessário compilar e distribuir novamente toda a parte de comunicação sem necessidade alguma.
A ilustração 2 demonstra como ficaria o design ao separar as responsabilidades.
Ilustração 2 - Interface modem separada
Para separar as responsabilidades da interface modem de modo que a aplicação não sofra de rigidez, foi necessário aumentar a complexidade do sistema. Todavia deve-se tomar muito cuidado ao aplicar o princípio, pois se os requisitos da aplicação fossem tais que sempre alterariam ambas as responsabilidades, conexão e comunicação, o novo design seria incorreto devido ao fato de ter gerado complexidade desnecessária à aplicação, outro odor da decomposição do software. Portanto a aplicação do princípio de divisão de responsabilidades, ou outro qualquer, deve ser feito de modo cuidadoso e inteligente. Só se deve utilizá-los se o design estiver exalando algum dos odores de decomposição do software.
Nenhum comentário:
Postar um comentário