Getters e Setters?
Logo quando comecei a programar orientado a objetos, percebi que muitas aplicações faziam o uso dos famosos pares get/set, então a primeira coisa que eu fazia ao construir uma classe, era pedir para que a IDE gerasse esses pares dos meus atributos privados antes mesmo de fazer qualquer coisa. Mas o que eu não me questionava, era sobre o real motivo do uso dessa dupla.
Hoje em dia vejo muitas aplicações que cometem esse mesmo equívoco que eu cometia há alguns anos atrás, fazem o uso do recurso (que nesse caso passaria a não ser um recurso) sem saber a razão, isso me remete até ao meu primeiro post.
Essa questão sobre o uso de getters e setters tem muito a ver como as coisas são feitas hoje em dia em relação ao desenvolvimento de software, principalmente em desenvolvimento para web, eu diria. Perdeu-se o seu principal foco, razões e objetivos e com isso surgem casos como o uso desenfreado dos getters e setters.
Getters e setters devem ser originalmente usados para encapsular seus atributos, evitando assim que eles sejam acessados diretamente. Dessa forma podemos aplicar determinada regra de negócio antes de atribuir valor a um atributo. Não é necessário, por exemplo, usar getters e setters em alguns objetos que serão imutáveis, ou então, apenas em objetos que servem para receber valor, nesses casos os getters e setters tornariam-se desnecessários.
Hoje em dia só faço o uso dessa dupla, quando realmente sinto essa necessidade, quando sei que meu atributo poderá vir a ter uma regra de negócio específica ou por algum motivo muito peculiar (ver mais abaixo), caso contrário, não uso. Em muitos casos passar os valores para o objeto utilizando o método construtor já resolveria o problema de forma simplória.
Deve-se considerar também, a possibilidade do seu software ser uma API aberta, usada e modificada por outros desenvolvedores, onde talvez você não tenha necessidade de um getter/setter, mas provavelmente para fornecer uma maior flexibilidade do código – considerando a possibilidade dele ser extendido – talvez seja interessante disponibilizar os tais pares. Da mesma forma que para debugar um código, talvez seja interessante fazer o uso de getters e setters para saber o valor que está sendo atribuído a uma variável, ao invés de espalhar milhões de breakpoint pelo código.
Links Interessantes
Fowler e Getters
Getter Erradictor
Why getter and setter methods are evil
Como não aprender Java e orientação a objetos
Se você gostou desse tópico, por favor considere deixar um comentário ou se inscreva no feed e tenha no futuro todos os tópicos entregues diretamente no seu agregador.
Muito obrigado pela informação, foi de grande valia.Paz e saúde para ti.
Olá Marcus (é assim mesmo o teu nome?). Pois bem, esta questão da dupla dinâmica vem sido motivo de muita confusão no domínio de desenvolvimento de aplicações OO, principalmente em Java. O maior problema é que nas Universidades você começa aprendendo que toda e qualquer classe precisa ter suas variáveis de instância encapsuladas; e como fazer? Definir o modificador de acesso como private e criar métodos públicos de acesso.
Mas para deixar claro e concordando com você, existem classes que não precisam ter alguns de seus membros como get’s and set’s. E tudo isso é oriundo de uma análise e modelagem real do problema orientada a objeto (UML, como padrão).
Parabéns pelo artigo.
Indico: http://fragmental.com.br/wiki/index.php/Fantoches [artigo de Phillip Calçado].
Saudações.
Olá Jidlafe (é assim mesmo teu nome? hehe), tudo bom?
Então, a questão é que muitas vezes as pessoas usam getters/setters sem saber o motivo, assim como eu já usei e provavelmente você tb. Mas com o passar do tempo, estudando e adquirindo experiência, você passa a se questionar sobre o “por quê?” das coisas e quando você chega nesse ponto, vc passa avaliar um monte de conceitos e técnicas que são pregadas e disseminadas, e não falo só de getters e setters não.
Eu conheço esse artigo do Phillip Calçado, realmente é muito bom, como a maioria das coisas que ele publica.
Um grande abraço e obrigado pela visita :)