Semântica aplicada quando bem aplicada ao desenvolvimento de desenvolvimento de software traz consigo bastante produtividade, diminuição de erros por confusão de idéias e maior confiança no produto final. Frameworks como Spring (que já não é propriamente somente um framework faz tempo) e o Hibernate surpreendem em uma série de características e uma delas é o esforço dos arquitetos visando a corretude semântica dos frameworks. Um breve exemplo baseado no Hibernate segue:
@Entity @Table(name = "user")public class User {
@Column(name = "firstname") private String firstName; @Column(name = "middlename") private String middleName;
@Column(name = "last_name") private String lastName;
@Embedded private Contact contact;
... Getters e Setters ...
}
A classe Contact é mapeada para User como um componente.
@Embeddable
public class Contact {
@Column(name = "contactfone")
private String fone;
@Column(name = "contactmail")
private String mail;
...
Getters e Setters
...
}
Num projeto real o código acima não deve figurar. Mas algo parecido pode acontecer e por hora serve de exemplo para o que quero falar. Com o mapeamento acima, as informações de Contact serão armazenadas na tabela de User (crianças, não façam isso em casa… nem no trabalho!). Então armazena-se uma instância de User na base de dados sem informar nenhum dado para Contact (talvez porque não seja obrigatório). O que aconteceria agora se fosse recuperado tal instância de User e executado um user.getContact()? Retornado uma instância de Contact com os atributos null? SIM!!?? Peraí, você acha semânticamente correto? Eu não acho e pelo visto o pessoal do Hibernate também não. user.getContact() retorna null uma vez que nenhum atributo é diferente de null (nenhum detalhe de Contact foi passado para a aplicação) e realmente creio que seja a coisa certa a ser feita.
Acredito que alguns dirão que não concordam. Cada um tem sua semântica, obviamente. Mas acredito que na maioria das situações features (ou issues para alguns) como essa trará bons frutos de produtividade.
