"
Apoiado por

Import/Export = Contrabando

O Java, uma linguagem de programação bem pensada, ajuda o programador a organizar o seu código obrigando-o a desenvolvê-lo de forma estruturada. A sua própria filosofia potencia o pensamento estruturado e promove coerência e arrumação.

Já o ABAP… promove o caos. Está cheio de caminhos perniciosos que levam direitinho a um inferno confuso e labiríntico. E geralmente são as coisas aparentemente mais convenientes que se revelam as mais perigosas.

Uma das conveniências piores é a parelha IMPORT e EXPORT.

Tão simples e conveniente! Mete-se algo na memória e depois, algures noutro sítio distante, lá está esse algo à nossa espera, disponível, mesmo à mão de semear. Caros leitores, não se deixem enganar. É preciso ser forte! Há que resistir à tentação de enveredar pela via da promiscuidade.

Usar IMPORT/EXPORT é contrabandear informação:

  • a leitura e a escrita ficam desconexas;
  • torna bastante difícil encontrar os IMPORTs e EXPORTs;
  • não é possível procurá-las através da “lista de utilizações”;
  • tendo encontrado um EXPORT podem existir mais, escondidos, noutro sítio totalmente diferente;
  • é fácil deixar lixo na memória que numa futura iteração não é correctamente inicializada e depois é o a ver se te avias.

Alternativas para evitar estes demónios em forma de comandos ABAP:

1. Parâmetros
Já vi situações em que se utilizava um EXPORT num programa que depois chamava uma função que fazia um IMPORT. Só a preguiça ou a ignorância podem explicar que isto aconteça em vez de se usar um simples parâmetro;

2. Variáveis globais de grupo de funções
Por vezes usa-se IMPORT/EXPORT para guardar o valor de uma variável entre várias chamadas de uma função. Uma forma mais saudável de conseguir o mesmo efeito é a utilização de variáveis globais, declaradas no TOP do grupo de funções. Pode-se por exemplo criar no mesmo grupo de funções uma função GUARDA_X que escreve o valor na variável global e outra função LE_X que lê o valor da variável, fazendo estas as vezes do EXPORT e do IMPORT respectivamente;

3. Artibutos estáticos de uma classe
Os atributos estáticos numa classe comportam-se da mesma forma que as variáveis globais do grupo de funções e podem ser usadas nas mesmas situações. Com a vantagem de uma classe ser sempre mais elegante e arrumada que um grupo de funções.

4. STATICS
Declarando uma variável local à função ou procedimento como STATICS obtém-se o mesmo efeito que com a utilização de variáveis globais pois esta guardará o seu valor entre as várias que é chamada. Com a limitação de a variável neste caso ficar disponível apenas para a função ou procedimento onde foi declarada, não podendo portanto ser usada para comunicar entre funções diferentes.

Haverá alguma situação em que seja inevitável usar esta funcionalidade horrenda? Talvez. Mas são menos do que se pensa. De qualquer forma o conselho do Abapinho é este: manter distância.

O Abapinho saúda-vos.

Actualização: O Bruno Filipa mostrou-me um exemplo onde realmente não parece haver forma de evitar usar IMPORT/EXPORT. Nas palavras dele: «Imagina que no meio do standard tens um submit. Precisas de aceder a dados “dentro do submit” que só tens disponíveis antes desse submit ser feito. Supostamente tendo um grupo de funções com uma variável global que é afectada antes do submit (num exit qq) e consultada dentro do submit resolveria o problema. Mas na verdade quando fazes um submit os valores das variáveis globais dos grupos de função vão à vida… Por outro lado com um IMPORT/EXPORT conseguirias resolver a questão». Realmente, nenhum das alternativas que proponho neste artigo funcionariam neste caso. Bolas.

11 comentários a “Import/Export = Contrabando”

  1. Pedro Lima Diz:

    Sem dúvida o import/export é terrível e infelizmente é usado de forma generalizada.

    Mas eu até gosto do statics. E uso normalmente para fazer funções que guardam valores em cache. Por exemplo uma função que recebe um código de um artigo e tem que fazer um select à tabela MARA para ir buscar um outro valor que é utilizado para calcular o retorno da função. Ao guardar os resultados do select dentro de uma tabela declarada como statics posso usar esta função dentro de um loop numa listagem de um relatório e sei que o select só será feito uma vez por cada artigo. Assim é possível fazer uma função reutilizável e que mantém boa performance.

    Claro que os puristas de objectos (java guys) fariam o mesmo com uma classe e atributos estáticos, e isso também pode ser feito em abap. Mas uma função é mais simples e simples é bonito.

  2. nununo Diz:

    Eu também gosto do statics e uso-o amiúde :) Mas estou cada vez mais virado para usar classes em vez de funções.

  3. Bruno Filipa Diz:

    Olá! :)

    Concordo plenamente com quase tudo o que disseste em relação aos IMPORT/EXPORT…

    A excepção é: “Haverá alguma situação em que seja inevitável usar esta funcionalidade horrenda? Talvez.”

    Substituiria o “Talvez” por um claro “Sim”. Infelizmente há mesmo situações, e já me deparei com algumas, em que nenhuma das alternativas funciona. Eu sou sempre da opinião de que não há nada que seja 100% mau :)

    No caso de nos depararmos com uma das situações em que esse horror tem que ser usado… Fica sempre bem colocar um comentário a dizer onde é feito o correspondente IMPORT/EXPORT. :)

    Abraço,
    Bruno

  4. admin Diz:

    Olá Bruno :)
    Tinha curiosidade em conhecer um desses casos em que não há volta dar aos IMPORT/EXPORT.
    Abraço,
    Nuno

  5. Bruno Filipa Diz:

    Olá Nuno!

    É giro o teu cepticismo em relação ao facto de que nem sempre a solução bonita funciona! :)

    Em relação ao que perguntas… Aqui fica um caso em que acho que nenhuma das soluções elegantes funciona mas o IMPORT/EXPORT funciona…

    Imagina que no meio do standard tens um submit. Precisas de aceder a dados “dentro do submit” que só tens disponíveis antes desse submit ser feito. Supostamente tendo um grupo de funções com uma variável global que é afectada antes do submit (num exit qq) e consultada dentro do submit resolveria o problema. Mas na verdade quando fazes um submit os valores das variáveis globais dos grupos de função vão à vida… Por outro lado com um IMPORT/EXPORT conseguirias resolver a questão.

    É verdade que o conceito do “Submit” já por si não é bonito…mas também é verdade que o standard tem montes deles e mais cedo ou mais tarde acaba por se ter que lá chafurdar…

    Esta questão eu testei apenas com a variável global dentro do FM, mas acho que em outras situações também já testei com os atributos estáticos em classes e o resultado é o mesmo.

    Abraço,
    Bruno

  6. admin Diz:

    Caramba. Tens razão…
    Quanto ao meu cepticismo… se fosse realmente cepticismo eu teria dito “Nunca” em vez de “Talvez” :) Chamemos-lhe relutância. Enfim…de qualquer forma tens razão… sou um romântico ah ah ah. Mas contra factos não há argumentos e, posto o teu exemplo, vou até actualizar o artigo, para veres como o meu lirismo é enxertado de realismo aqui e ali ;)

  7. João Martins Diz:

    Boas,

    Antes de mais paraPbens pelo excelente blog, já era sem tempo que apanhava um de qualidade e em português de Portugal :)

    Este tema está a moer-me a cabeça pois após ler o post eu próprio disse que ia acabar com os Export/Imports para a memoria mas após uns pequenos testes fiquei com uma duvida…

    Utilizando classes, imaginemos que num programa Z crio uma instancia de uma classe e utilizo um metodo para popular uma variavel com o valor pretendido.

    Algures no processamento, digamos numa exit, quero utilizar a mesma instancia para verificar qual o valor que foi inserido, mas … não consigo obter a instancia que foi criada e mesmo utilizando um singleton é sempre criada uma nova instancia… Bolas!!!! :)

    Como é que conseguem utilizar a mesma instância? Shared Objects?

    Abraços
    João Martins

  8. Bruno Filipa Diz:

    Olá João,

    A palavra chave nestas alternativas ao IMPORT/EXPORT é “STATIC” :)

    Ou seja, atributos estáticos e métodos estático.

    O que quer dizer que não será preciso instanciar objectos mas sim invocar um método estático da classe que dá o valor a um atributo estático da mesma classe.

    Mais à frente invocas um outro método estático para te devolver o valor do atributo e (em principio) já está! :)

    Abraço,
    Bruno

  9. João Martins Diz:

    Obrigado Bruno,

    Agora fez-se luz!! :) Estava a fazer um pequeno teste onde tinha reciprocidade do programa mas o gajo sempre que fazia o submit tinha o atributo estatico sempe limpo… Retirando o submit do programa e efectuando a chamada num modulo de função já tenho o atributo estatico com valor…

    Pelo que estou a entender sempre pelos comentarios que um submit é efectuado estes atributos estáticos são limpos e reincializados… Estou correcto? Se sim qual a forma de contornar isto?(sem Export/import claro :))

    Obrigado e abraços
    João Martins

  10. nununo Diz:

    Olá João,
    Como podes ver mais acima no comentário do Bruno de dia 26 de Novembro, um COMMIT pelo meio é exactamente o caso onde não há volta a dar-lhe ;-)
    Abraço,
    Nuno

  11. Rafael Paes Diz:

    Se utilizares os Comandos IMPORT e EXPORT dentro dos métodos (ex.: method_import e method_export) os Comandos estarão ligados e ratreados pelos métodos!? (exclamação e interrogação)
    Abraz.

Deixe um comentário


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).