Programação Procedural em Java

Ok, o título parece estranho, mas é algo que me preocupa: Afinal, POR QUE as pessoas confundem tanto desenvolvimento orientado a objeto com procedural? Recentemente eu fiz uma integração do Jasper com Ruby (projeto Jasper on Rails, no meu github) e me vi tendo que usar a API do Jasper. É mais ou menos assim (em JRuby):

  modelo = "#{DIR}/arquivo.jasper"
  dados = File.read("#{DIR}/dados.xml")
  str_reader = java.io.StringReader.new(dados)
  input_source = org.xml.sax.InputSource.new(str_reader)
  documento = JRXmlUtils.parse(input_source)

  params = {
    JRXPathQueryExecuterFactory::PARAMETER_XML_DATA_DOCUMENT => documento
  }
  fill = JasperFillManager.fill_report(modelo, params)
  pdf = JasperExportManager.export_report_to_pdf(fill)
  return String.from_java_bytes(pdf)


Ok, tudo bem… temos classes, temos métodos, mas… não parece estranho? Esse código é a cara dos códigos que eu já tive que fazer em pascal ou basic, com a diferença que eu acabo escrevendo MUITO mais porque eu preciso me entender com esse monte de Objeto.métodoEstático. A orientação a objeto não foi feita para evitar isso? Não seria mais belo se fosse possível escrever o código assim:
  modelo = "#{DIR}/#{modelo}.jasper"
  dados = File.read("#{DIR}/dados.xml")
  report = JasperReport.new_from_file(modelo)
  report.fill_report_from_string(dados)

  pdf = report.export_report_to_pdf(fill)
  return pdf.to_string

Simples, um “new” que cria um OBJETO, que recebe MÉTODOS… ao invés de classes funcionando como “containers de métodos” que nem o exemplo acima. Claro que no exemplo acima eu simplifiquei o máximo do máximo, mas ainda assim é possível fazer algo mais bonito. A idéia dos “params” é boa… para Ruby, aonde você declara um Hash praticamente sem dificuldade. E para Java, que você precisa IMPORTAR o HashMap, DEFINIR um novo HashMap, criar um monte de “add” (ou “push”, não lembro a sintaxe de Java) com um monte de constantes que estão dentro de uma classe, para DEPOIS passar isso para uma função… não seria mais fácil definir uma classe que recebe parâmetros tipo “setXmlDataDocument”?
Aonde eu quero chegar? Que mesmo se a linguagem te obrigar a usar um determinado paradigma, se a linguagem for simples, fácil de programar, ainda assim é possível escrever códigos mal escritos. Que a orientação a objeto não significa “tudo precisa estar numa classe”, significa que “uma classe representa um possível objeto, que tem comportamentos específicos”. Programar orientado a objeto significa pegar um objeto e mudá-lo até ele atender as suas necessidades, e então rodar algum comando que o transforma no que você quer. De preferência se você conseguir pegar algo que as pessoas fazem muito (como no caso do Jasper – imagino que muitos queiram gerar um PDF) e criar um método que automatiza todas as chamadas (digamos, um JasperReport#to_pdf, mais ou menos como eu fiz no exemplo acima) você finalmente criará um código LIMPO. Não interessa se aquele código que você escreveu só faz chamadas a outros métodos públicos.
E principalmente, mantenha o código conciso. Se você criou um método “to_pdf”, não crie outro “to_xls_file”. Mantenha as definições semelhantes (mais uma vez, no Jasper, eu tive que enfrentar coisas estranhas – alguns relatórios você precisa chamar o exportReportToPdf(), e outros você precisava criar um “Exporter”, falar que ele vai exportar para um Stream e depois chamar o “export” do exporter…).
Por fim, para quem entende inglês, segue um vídeo extremamente interessante: The Art of Application Development (http://www.mefeedia.com/watch/24603213)
Na dúvida, lembrem-se do princípio KISS – Keep It Simple, Stupid!
Share this:
Click to share on Twitter (Opens in new window)
Click to share on Facebook (Opens in new window)
Like this:
Like Loading...


	
Related