Be a Developer, not a Blender

Hello, how are you?

We live in a “frameworks that are easy to use” age that helps us to create our projects. One thing that a lot of teachers say is: “Just use this annotation and it will be ok”.

Annotations have the objective of making frameworks easier to use and identify their behavior, but some developers get lost with this feature and and they forget about some of the OO basics.

CRUD, JMS queues, Beans, transaction controls can be created in minutes, but what about the Object Orientation? What happened with the good practices that took a long time to be correctly forged? Why are they being abandoned?

Mixing Concepts

To understand better what I am trying to say, let us see below some code snippets  that we find in development sites. In the first sample we can see a code with JPA and JSON mixed:

@Entity
@XmlRootElement
@JsonAutoDetect
@DiscriminatorColumn(name = "animal_type")
@JsonTypeInfo(
        use = JsonTypeInfo.Id.NAME,
        include = JsonTypeInfo.As.PROPERTY,
        property = "type")
@JsonSubTypes({
        @JsonSubTypes.Type(value = Dog.class, name = "dog"),
        @JsonSubTypes.Type(value = Cat.class, name = "cat"),
        @JsonSubTypes.Type(value = Bird.class, name = "bird")
})
public class Animal {
 
    @Id
    private int id;
 
    @JsonSerialize(using = JsonDateSerializer.class)
    private Date birthday;
 
    @JsonView(ToothView.class)
    @OneToMany(mappedBy = "animal")
    private List<Tooth> teethList;
 
    // other stuff
}
 
@Entity
@JsonRootName(value = "Dog")
@JsonIgnoreProperties(ignoreUnknown = true)
public class Dog extends Animal {
 
    @JsonProperty
    private String name;
 
    @Convert(converter = JsonAttributeConverter.class)
    private Double weight;
 
    @JsonIgnore
    @OneToMany(fetch = FetchType.EAGER, mappedBy = "dog", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Bone> boneList;
 
    public Dog() {
    }
}

What is the problem with the code above? Why would someone mix JSON annotations (VIEW) with JPA annotations (MODEL)? If we need to edit an attribute only to display it in a different way in a VIEW, this update will affect the same class that is used to persist the data. We will increase the risk to input a bug when persisting the data.

No Respect for the Layers

Let us see another example:

@ViewScoped
@ManagedBean
@TransactionManagement(TransactionManagementType.BEAN)
public class ManagedBeanOne extends SuperManagedBean implements Serializable {
     // attributes
    public String doSomething() {
        try{
            transaction.begin();
            // do something
            transaction.commit();
        }
        catch(Exception ex){
            transaction.rollback();
        }
    }
}
 
 
@ManagedBean
@WebService
@ViewScoped
public class ManagedBeanTwo implements Serializable{}

Should the class be defined as a JSF ManagedBean and an EJB? The worst part of this code is: Why is a JSF class managing a transaction? What do we gain by giving this ManagedBean so many responsibilities?

Huge Code Blocks Do Not Help

A code that I could not post here is a class with more than 1k lines. The worst part of a huge class is that the some developers start to make jokes about it, or sometimes the class is considered to be a huge bad monster that should never be touched because any update would break the code.

How long will developers keep adding just one if statement to this kind of classes without doing small refactorings?

Exception that Dictate the Rules

A terrible practice is using an Exception to handle the request flow. Take a look below:

try{
    myObject.doSomething();
} catch(MyExceptionOne one){
    sendErrorSmsToCustomer();
    defineOldPlanToCustomer();
    sentToScreenOne();
} catch(MyExceptionTwo two){
    sendErrorEmailToCustomer();
    defineNewPlanToCustomer();
    sentToScreenTwo();
}

What would happen with the database data if an error is thrown at the first line of the exception block? What would happen if a developer invokes “myObject.doSomething()” in another class but without the correct catch code like above? What if the line code that handles the user plan is not executed?

What comes next?

It is an easy task to say if code looks good or bad, but I believe that one thing that is needed is to always to show a solution. What we will see in the pages to come is not something created by me, but are good practices and design patterns that you will find in several development books.

What we will see:

  • Page 2: Do not Pass Over the Layers
    • Pay Attention to the Packages
  • Page 3: Increase your Cohesion
  • Page 4: Loose Coupling
    • Facade is a Good Call
  • Page 5: Let us Return to the DTOs World
    • How can I easily pass the Entity data to a DTO?
  • Page 6: Small Classes and Methods
  • Page 7: How can we use Exceptions Correctly?
  • Page 8: The Broken Window Theory
    • Keep your build working
    • Do not leave your tests breaking
    • Do not comment/ignore your tests
  • Page 9: Good practices that helps
    • KISS
    • DRY
  • Page 10: It does not matter if you have a huge amount of tests without quality
    • Use Test Tools
    • Did you find a bug? Create a test for it
  • Page 11: Conclusion

I hope that this posts helps you. (:

I am really thankful for the Rodrigo Sasaki’s (http://cv.rodrigosasaki.com) help, this guy rocks!

Seja um Desenvolvedor, não um liquidificador

Olá, tudo bem?

Vivemos em uma época onde é muito fácil de criar projetos com frameworks “mágicos”. O que é ensinado em diversos blogs e faculdades é que: “basta anotar com isso aqui que está pronto”.

Anotações tem a função de facilitar a utilização e a identificação de comportamentos dos frameworks, mas existem desenvolvedores que se perdem com essa facilidade e acabam esquecendo de conceitos básicos.

CRUD, filas JMS, Beans, controle de transações podem ser criados em minutos, mas e a parte de Orientação a Objeto? Conceitos básicos do Java? O que tem acontecido para que as boas práticas que demoraram anos para serem desenvolvidas simplesmente serem abandonadas?

Misturando Conceitos

Para ser mais claro, vamos ver alguns exemplos de códigos postados por desenvolvedores em fóruns. No primeiro exemplo é possível ver a mistura de JPA com JSON:

@Entity
@XmlRootElement
@JsonAutoDetect
@DiscriminatorColumn(name = "animal_type")
@JsonTypeInfo(
        use = JsonTypeInfo.Id.NAME,
        include = JsonTypeInfo.As.PROPERTY,
        property = "type")
@JsonSubTypes({
        @JsonSubTypes.Type(value = Dog.class, name = "dog"),
        @JsonSubTypes.Type(value = Cat.class, name = "cat"),
        @JsonSubTypes.Type(value = Bird.class, name = "bird")
})
public class Animal {

    @Id
    private int id;

    @JsonSerialize(using = JsonDateSerializer.class)
    private Date birthday;

    @JsonView(ToothView.class)
    @OneToMany(mappedBy = "animal")
    private List<Tooth> teethList;

    // other stuff
}

@Entity
@JsonRootName(value = "Dog")
@JsonIgnoreProperties(ignoreUnknown = true)
public class Dog extends Animal {

    @JsonProperty
    private String name;

    @Convert(converter = JsonAttributeConverter.class)
    private Double weight;

    @JsonIgnore
    @OneToMany(fetch = FetchType.EAGER, mappedBy = "dog", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Bone> boneList;

    public Dog() {
    }
}

Qual o problema do código acima? Qual o motivo da mistura de anotações de JSON (view) com anotações do JPA (modelo)? Note que, por causa dessa mistura, qualquer campo que a view deva exibir de modo diferente afetará justamente a mesma classe utilizada para salvar dados no banco de dados.

Não respeitando as camadas

Vamos a outro exemplo:

@ViewScoped
@ManagedBean
@TransactionManagement(TransactionManagementType.BEAN)
public class ManagedBeanOne extends SuperManagedBean implements Serializable {
     // attributes
    public String doSomething() {
        try{
            transaction.begin(); 
            // do something
            transaction.commit();
        }
        catch(Exception ex){
            transaction.rollback();
        }
    }
}


@ManagedBean
@WebService
@ViewScoped
public class ManagedBeanTwo implements Serializable{}

Por que fazer de um ManagedBean de JSF também como um EJB? E até pior, por que deixar que um ManagedBean controle uma transação? Qual o ganho em deixar o ManagedBean com diversas responsabilidades?

Tamanho mais atrapalha que ajuda

Um exemplo que eu não tive como colocar aqui foi de uma classe com mais de 1k de linhas. A pior parte é saber que esse tipo de classe fica sempre como motivo de chacota, ou essa classe é tratada como um objeto de terror e espanto pois qualquer alteração quebra o sistema.

Até quando os desenvolvedores vão ter o hábito de sempre querer adicionar um if sem antes fazer um pequeno refactoring?

Exception que é Chefe

Outra prática terrível é deixar uma exceção controlar o fluxo. Veja como é fácil cometer esse erro:

try{
    myObject.doSomething();
} catch(MyExceptionOne one){
    sendErrorSmsToCustomer();
    defineOldPlanToCustomer();
    sentToScreenOne();
} catch(MyExceptionTwo two){
    sendErrorEmailToCustomer();
    defineNewPlanToCustomer();
    sentToScreenTwo();
}

No exemplo acima, o que aconteceria com os dados do banco se na primeira linha de uma exceção acontecesse um erro? O que aconteceria se algum desenvolvedor fosse executar a chamada myObject.doSomething(); em alguma outra classe, e não tratasse todos os erros como no exemplo acima? E se ele não adicionasse a linha onde não trata o plano do usuário?

E agora?

Falar dos problemas é fácil, mas eu creio que ser necessário mostrar soluções que podemos aplicar em nosso dia a dia para melhorar a qualidade de código. O que vamos ver nas próximas páginas não é nada inventado por mim, mas são práticas extraídas de livros sobre design patterns e boas práticas de programação.

O que veremos:

  • Página 2: Não transpasse camadas
    • Atenção nos pacotes
  • Página 3: Aumente a coesão
  • Página 4: Reduza o acoplamento
    • Facade é uma boa pedida
  • Página 5: Voltemos ao mundo dos DTOs
    • Como facilitar a cópia de uma Entity para um DTO
  • Página 6: Métodos e Classes pequenas
  • Página 7: Como usar exceção corretamente?
  • Página 8: Teoria da Janela quebrada
    • Mantenha seu build sempre funcionando
    • Nunca deixe testes quebrados
    • Não comente/ignore seus testes
  • Página 9: Boas práticas que ajudam
    • KISS
    • DRY
  • Página 10: Quantidade de testes não importa, mas sim a qualidade
    • Utilize ferramentas
    • Achou um bug? Crie um teste
  • Página 11: Conclusão

Espero que este post seja útil ao seu dia a dia. (:

Não poderia deixar de agradecer ao Rodrigo Sasaki (http://cv.rodrigosasaki.com/) que me deu uma força absurda na revisão do post.