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!

2 thoughts on “Be a Developer, not a Blender

Leave a Comment