Design Patterns

E quando Linguagem é ubíqua mas é Legada?

486 days

by higor.cesar in Arquitetura, Carreira, Design Patterns, pragmatísmo, Trabalho

Contexto do problema

Olá pessoal, como o texto sugere o assunto será a linguagem ubíqua de um projeto de migração de sistema. Atualmente participo de um projeto de migração de um sistema de workflow desenvolvido em VB 6 e coisas da época, Assim que cheguei a equipe teve o início de mudança de paradigmas. As mudanças ocorreram no processo de desenvolvimento, terminologias e tecnologias. O modelo antigo usava notação Húngara e as pessoas se comunicavam usando expressões do tipo: O método A espera os parâmetros idPart e tpSt. O que isso quer dizer? depende do método! A utilização de siglas fazia com que termos tivessem mais de um significado, em determinado contexto o significado era esse:

idPart = Id do participante
tpSt = Status

Todas as equipes envolvidas com o produto falavam a mesma língua mesmo que essa língua fosse dúbia as veze, O fato é que existia e ainda existe uma linguagem ubíqua.

Solução do analista/Arquiteto

Eu desempenho o papel de arquiteto nesse projeto(sei que muitos discordam quanto a consideração de arquitetura sendo um papel) e logo que começamos a desenvolver usamos novos padrões de nomenclatura, e isso significa:

Eliminação da notação húngara
Adoção do inglês como padrão
Diminuição da quantidade de siglas

Estamos desenvolvendo a nova versão do produto que inclui muitos produtos “acessórios” e tudo está ocorrendo razoavelmente bem, os clientes estão satisfeitos mas de fato poderia ser melhor(assunto para outro post), a equipe está razoavelmente acostumada com a tradução entre termos e tudo mais..O problema?

Hoje vejo que fui responsável por destruir parte da linguagem ubíqua!

Hoje vejo que a comunicação seria excelente sem traduções e etc., quando cheguei no projeto não tive a maturidade para ver que já existia uma linguagem e que todos estavam satisfeitos com ela. Fico feliz em hoje conseguir ver que fiz uma escolha precipitada.

É isso pessoal, gostaria de ouvir de outros desenvolvedores que passaram por esse embate entre uma linguagem ubíqua “Fora dos novos padrões” e uma nova linguagem que não é compartilhada pela equipe. Tem experiências? conta ai..

Domain Driven Design;DDD; Linguagem Ubiqua

Testes na camada de dados

713 days

by higor.cesar in Design Patterns, NUnit, pragmatísmo, Testes

Olá pessoal, vamos falar sobre a qualidade e ROI de testes para a camada de dados.Estava escrevendo uns testes para um projeto e reparei que os testes não me traziam ROI algum. Segue o código de exemplo, acho que vocês vão entender.

O problema!

Interface de repositório

/// <summary>
/// Repositorio para o tipo ObjectSummary
/// </summary>
public interface IObjectSummaryRepository
{
    /// <summary>
    /// Recupera um objectSummary de acordo com o cdObj
    /// </summary>
    /// <param name="cdObj"></param>
    /// <returns></returns>
    ObjectSummary GetObjectSummary(Int32 cdObj);
}

Segue uma implementação SQL do Repositório

internal class ObjectSummarySQLRepository : IObjectSummaryRepository
{
    private const string TABLE = "ObjectSummary";
    QueryManager queryManager;
  
    public ObjectSummary GetObjectSummary(int cdObj)
    {
        StringBuilder sbSQL = new StringBuilder();
        sbSQL.AppendLine("SELECT cdObj, dsTitle, dsSubtitle, obsSummary, nmFile, idLstRecipient, cssClassLogoClientCover,");
        sbSQL.AppendLine(" cssClassLogoASKCover, cssClassLogoClientDetail,cssClassLogoASKDetail, footer, flgShowFooterInCover, idGru");
        sbSQL.AppendLine(" FROM ObjectSummary WITH(NOLOCK) where cdObj=@cdObj ");
        String sqlCommand = sbSQL.ToString();
  
        NameValueCollection sqlParams = new NameValueCollection();
        sqlParams.Add("@cdObj", cdObj.ToString());
        return ConvertRowToEntity(queryManager.FetchSingleObject(sqlCommand, sqlParams).Rows[0]);
     }
}

Uma implementação fake do repositório para testar em memória

public class ObjectSummaryFakeRepository : IObjectSummaryRepository
   {
       public ObjectSummary GetObjectSummary(int cdObj)
       {
           if (cdObj == 1)
           {
               ObjectSummary objectSummary = new ObjectSummary();
               objectSummary.ObjectSummaryID = 1;
               objectSummary.CssClassLogoASKCover = "CssClassLogoASKCover";
               objectSummary.CssClassLogoASKDetail = "CssClassLogoASKDetail";
               objectSummary.CssClassLogoClientCover = "CssClassLogoClientCover";
               objectSummary.CssClassLogoClientDetail = "CssClassLogoClientCover";
               objectSummary.FileName = "FileName";
               objectSummary.Footer = "Footer";
               objectSummary.GroupID = 1;
               objectSummary.ListRecipientID = 1;
               objectSummary.ShowFooterInCover = true;
               objectSummary.SubTitle = "SubTitle";
               objectSummary.Summary = "Summary";
               objectSummary.Title = "Title";
               return objectSummary;
           }
           return null;
       }
   }

Alguns testes:

[TestFixture]
public class TestObjectSummaryRepository
{
    private IObjectSummaryRepository objectSummaryRepository;
  
    [SetUp]
    public void SetUp()
    {
        objectSummaryRepository = new ObjectSummaryFakeRepository();
    }
    [Test]
    public void TestGetGetObjectSummary_NonExistent()
    {
        Assert.IsNull(objectSummaryRepository.GetObjectSummary(2));
    }
    [Test]
    public void TestGetGetObjectSummary_ShouldReturnValueObject()
    {
        Assert.IsNotNull(objectSummaryRepository.GetObjectSummary(1));
    }
}

Como vocês podem ver os testes não trazem ROI algum! Qual o sentido de testar se existe um objeto no contexto fake? esses são tipos de testes para o ego.

Melhores opções

1-Podemos escrever os testes usando transações, inserindo dados para os testes no SetUp e excluindo-os no TearDown. Desta maneira estaremos ao menos testando o código SQL. O problema é o tempo que os testes vão levar..

2-Podemos usar as coleções em memória apenas para testar relacionamentos entre os objetos.

Continuação da discussão

Este assunto é debatido no grupo DNA

Não existe nada mais facil que o novo ASP.NET MVCThere isn’t anything easier than the new ASP.NET MVC

909 days

by higor.cesar in asp.NET, Design Patterns, MVC

Olá pessoal,

Eu estou brincando no asp.net mvc desde o preview 6 dele, como você pode ver há muitas pessoas tentando melhorar a qualidade do software através do MVC. Eu posso dizer que minha experiência com esta tecnologia está sendo legal.

A questão desse post, é que como qualquer nova tecnologia há muitos iniciantes tentando, com isso essas pessoas não tem cuidado sobre padrões e melhores práticas, assim provavelmente elas estão fazendo o mesmo que elas fariam com webforms.

O engano mais comum é causado pela incompreensão dos conceitos básicos do MVC, onde pessoas ainda entendem que o MVC é como:

M – Significa o lugar onde você coloca seus modelos, dados ou coisas relacionadas;

V – Seu código html, a interface com o usuário;

C – Todos os códigos que fazem a aplicação rodar.

Eu estava tendo uma conversa com um meu e ele disse que coloca a regra de negócio dele dentro do controller. Eu sugeri a ele colocar o código em um outro projeto e usar o controller apenas para gerenciar requisições e questões relacionadas. Ele disse que faria isso mas onde iria colocar os dados dele? Eu acho que em outro projeto também. Neste modo ele acaba apenas adicionando referência para o negócio e o projeto de dados dentro do projeto web dele.

Todo esse texto foi apenas um exemplo. Eu estou preocupado sobre como as pessoas tendem a usar o MVC, em uma mão há muitas pessoas gastando tempo sugerindo melhores práticas mas na outra há pessoas que não se importam com isso.
Eu li em um post de alguém que disse:

“Não é suficiente construir aplicações sobre os padrões, você ainda poderá fazê-las pobres e fracas.”

Ps.: Eu sei que eu posso melhorar meus projetos MVC. Eu também sou uma dessas pessoas descritas

Olá pessoal,

O engano mais comum é causado pela incompreensão dos conceitos básicos do MVC, onde pessoas ainda entendem que o MVC é como:

M – Significa o lugar onde você coloca seus modelos, dados ou coisas relacionadas;

V – Seu código html, a interface com o usuário;

C – Todos os códigos que fazem a aplicação rodar.

“Não é suficiente construir aplicações sobre os padrões, você ainda poderá fazê-las pobres e fracas.”

Ps.: Eu sei que eu posso melhorar meus projetos MVC. Eu também sou uma dessas pessoas descritas

Software:OrtogonalidadeSoftware:Orthogonality

944 days

by higor.cesar in Arquitetura, Design Patterns, pragmatísmo

O conceito de ortogonalidade é conhecido e usado por muitos projetistas de software, e você, Conhece e faz uso desta técnica?

O exemplo legal de explicar ortogonalidade é o exemplo do controle de um helicóptero onde todos os dispositivos quando acionados causam impactos em outros, quando um botão é acionado a alavanca deve ser puxada. Neste exemplo você pode ver que fica difícil alterar o funcionamento de um dos itens, afinal de contas você vai ter que testar todas as combinações possíveis, pois o comportamento é determinado pela combinação.

Baseado no exemplo do parágrafo anterior pode concluir que os controles são componentes do sistema, sendo assim se quando um componente é alterado outros componentes param de funcionar é sinal que as coisas não estão ortogonais.

Ortogonalidade é próximo do conceito de coesão, onde um componente deve ser independente possuindo um único e bem definido propósito [yourdon,constantine].Sendo assim se a interface pública do componente não é alterada todos os outros componentes relacionados continuarão funcionando da mesma maneira.

Criar componentes ortogonais envolve um conjunto de boas práticas de desenvolvimento, podemos citar os princípios como KISS e o YAGNI além dos padrões de projeto. Alguns dos benefícios de utilizar sistemas ortogonais são estes:

Manutenção

Os compontes se comunicam por interfaces simples e claras logo é relativamente simples alterar o comportamento e a forma de interação.

Testabilidade

Os componentes são mais fáceis de testar visto que testes unitários tornam-se uma opção viável.

Redução de riscos

Alterações causam problemas apenas se as interfaces forem alteradas.

Design aprimorado

A aplicação como um todo fica mais simples de ser aprimorada ou extendida.

No livro The pragmatic programmers podemos encontrar uma vantagem adicional que diz o seguinte:

“Quando dois controles A e B respectivamente com funcionalidades K e Y são mesclados obtemos K*Y funcionalidades. De outra maneira quando mesclamos controles C e D não ortogonais com funcionalidades X e Y não obtemos o mesmo número de funcionalidades do mesmo caso visto que a junção sobrepõe funcionalidades duplicadas”

Ortogonalidade é fortemente relacionado com a coesão, portanto se você quer aumentar a ortogonalidade de seus componentes fique atento para as responsabilidades e objetivos deles.Orthogonality is a famous concept for software designers, and you, do you know this concept? Are you familiar with this technique?

The coolest sample to explain this is the helicopter sample. In this case all controls cause a side-effect in another control. So if you press a button you need to push the lever. As you can see is really hard to change the way things work. If you change one control you have to test the entire set of possibilities related.

Based upon the sample above we can realize that components could be your software components, so if you change one of your components and things stop working it could mean that you have a problem

Orthogonality is closed for cohesion concept, when a component should be independent and with only one clear purpose [Yourdon, Constantine]. Thus if there is any change in your system’s public interface all others should continue working in as before.

Build components involves a lot of development best practices, for instance KISS and YAGNI. In addition to it you should use design patterns. Here are some benefits when applying Orthogonality in your system’ components:

Maintenance:

Components are related by clear and simple interfaces, so is easier to change your code and the interaction of your components.

Testability

The whole system is easier to test. In addition to it you can create unit tests.

Risk Reduction

Changes are not so boring if its interfaces are not changed

Better design

Is easier to improve your application

Reading the Pragmatic Programmers Book you can see the following benefits:

“If controls A and B with functionalities K and Y are related we can get K*Y functionalities. In another hand if these controls are not well designed control ‘A’ will overlap control b, so you will not get K*Y functionalities anymore”

Orthogonality is strongly related to cohesion, so if you want to improve it in your system pay attention to its responsibilities and purposes

Refatoração para padrões

1045 days

by higor.cesar in Arquitetura, Design Patterns, Livros, Refatoração, XP

Fala galera, como mencionei em uns posts anteriores estou comprei o livro refatoração para padrões. Ontem iniciei a leitura e acho que já valeu a pena! Sinceramente esperava um “guia” de refatorações envolvendo padrões, algo similar ao livro de Refatoração do Fowler, mas achei muito mais.

O livro foi escrito pelo Joshua Kerievsky, o cara é evangelista de programação extrema e padrões, sendo assim ele responde uma pergunta que eu vinha me fazendo.

“A programação extrema prega o projeto no momento certo e com a solução mais simples para um dado problema. Os padrões são soluções extensíveis e reutilizáveis e adicionam um pouco de complexidade ao projeto. Como deve ser a utilização de padrões em projetos que seguem o XP?”

A capa do livro responde minha pergunta.

“Refatoração para padrões”

Como?

“O autor prega que durante uma refatoração é um bom momento para inserir ou projetar em direção aos padrões”

Seguindo o método acima conseguimos resolver dois problemas recorrentes no desenvolvimento de software, o primeiro deles o excesso de “projeto” no início do desenvolvimento, este seria o grande investimento em soluções super extensíveis que podem não ser usadas(YAGNI). O segundo problema ainda pode ser pior que o primeiro, esse acontece quando nenhum investimento no projeto foi feito.

O livro é de grande serventia para aqueles que usam XP como metodologia ou ainda todos aqueles que se preocupam com o momento certo de inserir um padrão de projeto no código.

Why should I use constructors?

1130 days

by higor.cesar in Design Patterns, POO

Hello people,

Today I had a talk with a friend of mine, we were having class at college and we were making some classes files in Java and I don’t know why but he asked me if I had created the constructor for these class, at the same time I asked him: “Why should I create constructors?”, He answered me what I was hope, he said me that using constructors we can put the complexity of object’s creation in a specific place, So I suggest him why not use the Factory pattern for this? He answered me that sometimes there is no reason to increase the complexity using patterns, so I agree because it is related to KISS principle.
After this little discussion I said that we can use constructor when an object must have some properties with correct values, so using constructor we have a way to create valid objects. I think that it is related with some patterns that and composition principle. Anyway when I read about Object oriented principles I never see any good explanations and tips about constructors. So, if you have more reasons or tips let me know.

Coding Standards

1214 days

by higor.cesar in Design Patterns, OpenSource

Fala galera, estou disponibilizando um link contendo um documento sobre padrões de codificação em c#. A primeira versão do documento foi desenvolvida pelo Clint Edmonson da MS. Eu editei o documento para adequá-lo ao projeto em que estou trabalhando. O documento é protegido pela licença GNU, portanto é possível utilizá-lo de várias maneiras.

O poder das Interfaces

1329 days

by higor.cesar in Design Patterns, POO

Fala galera, vocês certamente conhecem os conceitos de interfaces e classes abstratas em poo.Este post vem falar um pouco destes conceitos muitos famosos mas pouco usados com sabedoria.Bem, esta informação surge da minha experiência com livros e o ensino de oo.Quando perguntava as pessoas qual era a finalidade do uso de interfaces ela me respondiam:
- Interfaces são usadas para definir um contrato de uso com os objetos que a utilizam

Nunca me disseram alguma coisa mais interessante sobre interfaces. A grande parte dos livros de poo que eu li abordavam muito mal o uso dessa estrutura, é importante ressaltar que não me refiro aos tradicionais e excelentes livros de oo existentes. Estou me referindo a livros brasileiros e outros alguns exemplares estrangeiros.
Há muito tempo eu li um livro de php+padrões de projetos e li um principio de design de software que achei muito interessante:

“Programe para uma interface”

Mesmo tendo lido isso há algum tempo, só hoje começo a reconhecer a importância e o poder desta estrutura. Este conhecimento é devido à leitura que estou realizando, lendo Padrões de projeto use a cabeça reparei no constante uso desta estrutura para permitir flexibilidade.Acredito que muitos de vocês conheçam padrões de projeto, logo sabem do que estou falando.
A lição de moral deste post é procure aprofundar-se na real aplicação da programação orienta a objetos.Desta maneira vocês podem fugir das definições pobres e insuficientes.

Design Patterns

Categorias