No dia a dia de um arquiteto, é comum perceber a imensa redundância de código, pois grande parte dos desenvolvedores possui uma imensa dificuldade para identificar quem é responsável pelo que em seus códigos. Eles, em geral, estão preocupados em colocar seus códigos para funcionar custe o que custar, e custa caro tal irresponsabilidade “natural”. Com base nisso, veremos a partir de um Cenário demonstrar como identificar a governança correta. O exemplo é meramente ilustrativo, foi utilizada uma funcionalidade simples que geralmente é colocada fora do seu devido lugar.
Figura 1: Identificar a governança é como montar um quebra cabeças, mas o resultado final é sempre gratificante
Cenário:
Em nosso sistema possuímos Mensagens (Alert, Dialogs) disparados utilizando o mesmo padrão, mudando apenas a mensagem e possivelmente um redirect ou não.
Solução Senso Comum:
O desenvolvedor chama uma rotina que dispara a Mensagem na tela e a coloca dentro de cada formulário web, assim tendo que replicar o mesmo código a cada novo formulário.
Listagem 1: Implementação de Mensagem de alerta
ScriptManager.RegisterStartupScript(page, page.GetType(), identificador,
"alert('Alteração realizada com sucesso');", true);
Entendendo um pouco de Governança e Orientação a Objetos
Quando implementamos um código, temos que nos ater ao local em que o depositamos, pois atribuímos ao repositório dele a responsabilidade pelo mesmo. Sabendo disso pense um pouco, será que é responsabilidade de um formulário web tratar o alerta de mensagem? Não seria correto pensar que ele é apenas responsável pela chamada de alerta? É a governança de alertas ser uma classe de alerta, e que nela seja encapsulada todas as formas de alertas de seu sistema, tratando suas particularidades, frameworks utilizados como JqueryUI, EXJs, etc.
Sempre reflita se o que esta fazendo é responsável por aquilo que faz, sabemos que é comum construirmos classes com métodos alienígenas a ela e pior, métodos que fazem muito mais do que foi definido, por exemplo um método chamado “MisturarCafeComLeite” pode estar colocando apenas café e misturando com nada, ou seja fazendo menos do que foi definido, ou as vezes além de misturar café com leite coloca açúcar, o que seria um erro crasso pois estaria indo além de sua responsabilidade.
Além disso, podemos verificar que o principio SOLID foi desrespeitado. SOLID é a abreviação dos cinco primeiros princípios básicos da programação orientada a objetos, que foi introduzida por Michael Feathers no da primeira década de 2000. Alguns escritores como Kent adoram atribuir cheiro ao software e esse cheio basicamente é medido através do respeito a esse principio, cujo significado de cada uma das letras é:
- S (Single Responsibility): Um objeto deve possuir apenas uma responsabilidade.
- O (Open-Close): Entidades devem ser abertas para extensão, mas fechadas para alteração.
- L (Liskiv substitution): Objetos de cliente muito especifico devem ser substituivel por instancias de seus subtipo.
- I (Interface segregation): Pequenas e especificas interfaces é melhor à uma interface generica
- D (Dependency inversion): Não dependa de implementações concretas e sim de Abstrações.
Problema da implementação:
A Solução apresentada pelo programador comum que chamaremos de John Doe, como vimos não respeita o principio SOLID, uma manutenção ou alteração no sistemas deixaria John e sua equipe em apuros, pior ainda se John Doe por algum motivo deliga-se da empresa. Em sua solução ele atribuiu como vimos a responsabilidade sobre o alerta a cada formulário e não a um repositório de alertas, o que deixou o alerta fora de governança gerando várias dificuldades técnicas e duplicação desnecessária de código, imagina termos que ir formulário a formulário corrigir um erro na mensagem de alerta ou então alterá-la? Seria um trabalho árduo, além de ser um multiplicador de erro, pois a possibilidade de errar é multiplicada pela quantidade de vezes que o código repete-se.
Solução:
A solução para o problema é a criação de uma classe que será delegada a responsabilidade de disponibilizar as funcionalidades, que podem ser usadas de forma genérica pelos formulários, ou, caso precise, podemos criar uma classe especifica para Alertas, mas isso depende do caso. No nosso caso por não termos muitas funcionalidades de alerta e sendo nossa intenção apenas desacoplar do formulário funcionalidades que podem ser usadas de forma genérica, então podemos criar uma classe de Funcionalidades do Formulario, e nela colocaremos o nosso código.
Listagem 2: Código de Alerta deslocado para a governanca correta
public static class FormularioFuncionalidades
{
public static void Alert(Page page, string mensagem, string identificador)
{
string strScript = "alert('" + mensagem + "')";
ScriptManager.RegisterStartupScript(page, page.GetType(), identificador, strScript, true);
}
}
Em nossos formulários web chamaríamos o alert dessa maneira:
Listagem 3: Chamada do Metodo de Alerta
FormularioFuncionalidades.Alert(page, "Atualização efetuada com sucesso.", href, "OK2");
Vantagens:
Respeitamos o princípio SOLID, nossa classe e método possuem apenas uma responsabilidade, prontos para extensão, etc. Pensando ainda na solução, imagine que agora queremos implementar um redirect e que a Mensagem seja disparada utilizando Jquery UI, nesse caso seria fácil fazê-la com a governança correta, vejam que ao fazermos as alterações sugeridas todos formulários passaram a usufruir das novas funcionalidades.Listagem 4: Alteração do método com novas funcionalidades
public static void Alert(Page page, string mensagem, string href, string identificador)
{
page.Controls.Add(PreparaMensagem(mensagem));
ScriptManager.RegisterStartupScript(page, page.GetType(),
identificador, PreparaScript(href), true);
}
private static string PreparaScript(string href)
{
string strScript = string.Format("$(document).ready(function () {"
+ "$('#dialog').dialog({"
+ " modal:true,"
+ " width: 400,"
+ " show: 'drop',"
+ " hide: 'drop',"
+ " resizable: false,"
+ " buttons: {"
+ " Ok: function () {"
+ " $(this).dialog('close');"
+ " }"
+ " }"
+ "}).bind('dialogclose', "
+ " function(event, ui) "
+ " { {0}"
+ " }"
+ ");;"
+ "});", (string.IsNullOrEmpty("")) ? "" : "window.location.href = '" + href + "'; ");
return strScript;
}
private static Literal PreparaMensagem(string mensagem)
{
return new Literal() { Text = String.Format("<div id="dialog" title="Titulo"><p>{0}</p></div>",
mensagem) };
}Conclusão:
Respeitar os princípios SOLID nos leva a construirmos códigos mais elegantes e de fácil manutenção. Podemos ver que ao encapsular a chamada de mensagem, além de podermos facilmente corrigir um erro que esteja nesse código, também nos facilita a extensão e modificação do mesmo, caso precisemos.
"Qualquer tolo consegue escrever código que um computador entenda. Bons programadores escrevem código que humanos possam entender." (Martin Fowler)
