Para mantermos a sanidade, um pouco de humor para o final de semana, com os créditos para o Custódio de Oliveira, obrigado @zcust01!

Keep Calm and Call de ABAPer

Keep Calm and Call de ABAPer

Keep Calm and /H na MIRO

Vídeo muito interessante sobre Scrum. Em inglês.

Na busca pela solução de um problema, debugando, debugando e debugando novamente, me deparei com a criação dinâmica de objetos.

Estudando mais a fundo, eis que surge assunto para mais um post! Afinal, quanto mais dinâmicos forem os programas e API´s, melhor será sua performance e re-usabilidade.

O que faz com que consigamos criar o objeto / chamar o método dinamicamente, é a utilização de uma tabela, na qual informamos todos os parâmetros necessários (seja de importing, exporting, changing, etc), ou seja, podemos popular esta tabela de acordo com nossa necessidade em determinado ponto do programa.

Utilizei como exemplo, a criação de um objeto com referência à classe ‘CL_GUI_ALV_GRID’, o qual chamei de r_grid.

Para facilitar o entendimento, segue abaixo o Pattern (modelo) da criação estática deste objeto:

CREATE OBJECT r_grid
    EXPORTING
*      i_shellstyle      = 0
*      i_lifetime        =
      i_parent          = r_container
*      i_appl_events     = space
*      i_parentdbg       =
*      i_applogparent    =
*      i_graphicsparent  =
*      i_name            =
*      i_fcat_complete   = space
*    EXCEPTIONS
*      error_cntl_create = 1
*      error_cntl_init   = 2
*      error_cntl_link   = 3
*      error_dp_create   = 4
*      others            = 5.

OBS: o objeto r_container é do ripo CL_GUI_CUSTOM_CONTAINER , criado estaticamente no código abaixo.

Vamos criar o objeto apenas informando o parâmetro obrigatório ‘I_PARENT’, e para isso, utilizaremos uma workarea do tipo abap_parmbind, e uma tabela tipo abap_parmbind_tab, denominadas lwa_param e lt_param respectivamente.

Na propriedade ‘Name’ sempre informaremos o parâmetro, neste caso ‘I_PARENT’.

Na propriedade ‘Kind’, o tipo (Exporting, conforme modelo estático).

Para informar o tipo, precisamos utilizar os atributos da classe ‘CL_ABAP_OBJECTDESCR’, com isso, teremos:

lwa_param-kind = cl_abap_objectdescr=>exporting.

Por fim, necessitamos informar o valor atribuído a este parâmetro, e conforme podemos verificar no código abaixo, o valor é o objeto r_container (objeto de referência a classe CL_GUI_CUSTOM_CONTAINER).

Desta forma, necessitamos incluir a referência do objeto na tabela:

GET REFERENCE OF r_container INTO lwa_param-value.

Agora é só inserirmos nossa workarea na tabela e criarmos o objeto / chamarmos o método (não se esqueça de utilizar o try-catch, de forma a tratar possíveis exceções).

Obs: Verifique a sintax de chamada do método / criação do objeto. Observe que cria-se o objeto do tipo de uma classe (informada na variável lv_type) com os parâmetros inseridos na tabela.

REPORT  z_create_dinnam.
 
  TYPE-POOLS: abap.
 
  DATA: lt_param   TYPE abap_parmbind_tab,
        lwa_param  TYPE abap_parmbind.
 
  DATA: lv_type    TYPE string,
        lv_exc_txt TYPE string.
 
  DATA: r_except    TYPE REF TO cx_root,
        r_grid      TYPE REF TO cl_gui_alv_grid,
        r_container TYPE REF TO cl_gui_custom_container.
 
  CLEAR:   lt_param, lwa_param, lv_type, lv_exc_txt.
  REFRESH: lt_param.
 
*--------------------------------------------------------------------*
START-OF-SELECTION.
 
  CREATE OBJECT r_container
    EXPORTING
      container_name              = 'CONTAINER_1'
    EXCEPTIONS
      cntl_error                  = 1
      cntl_system_error           = 2
      create_error                = 3
      lifetime_error              = 4
      lifetime_dynpro_dynpro_link = 5
      OTHERS                      = 6.
  IF sy-subrc NE 0.
    MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
               WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
  ENDIF.
 
*--------------------------------------------------------------------*
  CLASS cl_abap_objectdescr DEFINITION LOAD.
 
  lv_type = 'CL_GUI_ALV_GRID'.
 
  lwa_param-name = 'I_PARENT'.
  lwa_param-kind = cl_abap_objectdescr=>exporting.
  GET REFERENCE OF r_container INTO lwa_param-value.
  INSERT lwa_param INTO TABLE lt_param.
 
*--------------------------------------------------------------------*
 
  TRY .
      CREATE OBJECT r_grid
        TYPE
          (lv_type)
        PARAMETER-TABLE
          lt_param.
 
    CATCH cx_sy_create_object_error INTO r_except.
      lv_exc_txt = r_except->get_text( ).
      MESSAGE lv_exc_txt TYPE 'I'.
 
  ENDTRY.

Fica o desafio: que tal chamar um método dinamicamente e utilizar uma tabela de excessão? Ela funciona da mesma maneira para recuperar as exceções lançadas pelos métodos. Pesquise, tente fazer e em caso de dúvidas, entre em contato!

Uma das técnicas de programação mais incompreendida e evitada, também é umas das mais poderosas, a Recursividade. Eu precisei usar a recursividade apenas uma única vez na vida com ABAPer e o resultado foi muito interessante.

Nesse texto eu vou resolver um problema muito simples usando recursividade, exponenciação.

Exponenciação

De acordo com  a Wikipédia:

Exponenciação ou potenciação é uma operação matemática, escrita como An, envolvendo dois números: a base a e o expoente n. Quando n é um número natural maior do que 1, a potência an indica a multiplicação da base a por ela mesma tantas vezes quanto indicar o expoente n.

A fórmula da exponenciação é simples e por isso considero um exemplo legal para mostrar a recursividade em prática.

Exponenciação Usando Recursividade

No ABAP você pode usar o operador ** para fazer a exponenciação e resolver todo o problema em uma linha (veja no programa abaixo), mas esse post não é sobre exponenciação, mas recursividade.

Novamente da Wikipédia:

 A recursão é o processo pelo qual passa um certo procedimento quando um dos passos do procedimento em questão envolve a repetição completa deste mesmo procedimento. Um procedimento que se utiliza da recursão é dito recursivo. Também é dito recursivo qualquer objeto que seja resultado de um procedimento recursivo.

Em ABAP claro significa uma subrotina (form, módulo de função ou método) que efetua uma chamada dela mesmo.

Por exemplo, usando a recursão para resolver um problema de potência, farei com que o método EXECUTE_EXPONENTIATION( ) seja chamado inúmeras vezes por ele mesmo, de acordo com o expoente passado para ele como parâmetro.

Também poderíamos usar a estrutura de loop DO n TIMES … ENDDO, mas aí não seria recursão.

Veja o programa abaixo:

ZABAP101_RECURSION

Execute esse programa no modo debug e veja a pilha de chamada. Veja que o método se repete várias vezes indicando que ele fora chamado de dentro dele mesmo, caracterizando uma recursividade:

Pilha de chamadas do método EXECUTE_EXPONENTIATION( ) – Recursividade

A primeira linha do método incrementa o atributo INTERECTION, daí o método chama ele mesmo se a interação for menor ou igual ao expoente. Com isso a pilha (stack) vai sendo adicionada a cada nova chamada até que o número máximo de iterações (expoente) seja alcançado.

A pilha pára de ser incrementada e o restante do método começa a ser chamado, a partir do item da pilha mais novo (LIFO, Last In First Out), onde finalmente a multiplicação é feita e sendo acumulada no atributo POWER.

Explosão de Lista Técnica

Existem problemas em que a recursividade é quase que obrigatória, no caso da chamada explosão de lista técnica.

Imagine que você precise saber o custo de algum material que é composto por outros materiais, como por exemplo um notebook.

Partes de notebook – fonte imagem

Um notebook pode ser um materia formado por teclado, display LCD, HD, placa-mãe, memórias, carcaça etc.

O teclado é formado por uma base, uma tecla Q, outra W, outra E, outra R, outra T etc.

Um HD é formado por um conjundo de discos magnéticos, placa de controle e sistema de leitura,

Um sistema de leitura é formado por um braço de leitura, cabeçote de leitura e placa de leitura.

E assim por diante.

Se eu tivesse uma rotina que dado um material ele me retornasse uma lista de materais que formam esse material, eu precisaria chamar essa rotina n vezes, conforme eu fosse “desmontando” ou “explodindo” meu material.

Dessa maneira a haveria a recursividade como exemplificado no exemplo do notebook, resolvendo o problema muito rapidamente.

Claro que nem tudo são flores. Depurar um programa que usa recursividade é muito trabalhoso, bem como entender a recursividade que outra pessoa desenvolveu. Isso faz com que a recursão seja evitada, mas em alguns casos é a melhor forma de resolver um problema.

Depois de falarmos do Singleton, está na hora de falarmos de outro padrão de projeto, o Factory. O Factory é mais difícil de entender do que o Singleton. Mais do que isso, mais difícil de mostrar alguma aplicação prática.

Nesse post eu mostrarei as duas coisas, explicar o funcionamento do Factory, bem como sua aplicação.

Rápida Explicação …

De uma maneira bem simples, o Factory é um padrão que nada mais é do que uma classe geradora de objetos, onde a decisão de qual classe o objeto será é feita pela classe “geradora”.

Onde eu apliquei o Factory em ABAP?

Projeto Code Coaching

Estamos trabalhando num projeto open source chamado Code Coaching que está sendo desenvolvido sob a iniciativa do ABAP101 Open Source.

O objetivo do projeto é construir uma aplicação ABAP onde o Programador e Coordenador possam se comunicar pelo próprio programa ABAP.

Veja esse exemplo. Esse trecho de código faz parte de outro projeto em que estávamos envolvidos. Eu queria passar instruções para a implementação de uma classe interface específica. Então ao invés de passar instruções por e-mail, eu resolvi colocar alguns comentários dentro do próprio código. Daí para evoluir para uma proto-markup-language foi um pulo (lembre-se, meu sangue é de programador, minha tendência é resolver tudo com um programa de computador).

Fonte

Existem algumas linhas de comentários que são iniciadas por *@. Essas linhas contêm uma espécie de código que dá um significado especial às linhas comentadas logo na sequência. Continuando na linha do *@ encontramos a seguinte instrução: “jack:task”. Isso significa que os comentários logo abaixo dessa linha, trata-se de uma tarefa designada para o programador chamado Jack.

Sendo assim, o programador pode facilmente fazer uma busca no programa pelo seu nome e descobrir todos os pontos que possuam algum comentário para ele. Para facilitar eu automatizei essa busca em um programa que lê o programa e extrai todos os pontos onde a linha começa com *@ e gera um relatório, como o mostrado abaixo.

Protótipo do relatório para o Code Coaching

Esse programa é apenas um protótipo e como tal serve apenas para apresentar e testar a ideia central do projeto. O projeto final contemplará muitas outras funcionalidades bem como outros comandos, muito além do task. É nesse ponto que o factory será usado.

O que o Factory Significa para o Code Coaching?

No protótipo do programa Code Coaching, ele consegue interpretar apenas o comando task, mas já no primeiro release, estamos planejando expandir para pelo menos três outros comandos além do task,  question, answer e comment.

Para fazer a interpretação desses comandos, o programa relatório contará com um diagrama de classes semelhante ao apresentado abaixo:

Teste de Conceito do modelo do Code Coaching

Cada comando é representado por uma classe. Abaixo você verá mais um programa de teste de conceito, este usando o factory para interpretar um comando entrado pelo usuário.

Implementando o Factory em ABAP

Vamos para mais um programa que simula o interpretador que usaremos no Code Coaching. Trata-se de um programa bem simples, com um parâmetro que é o nome do comando. Se o comando existe, ele mostra o texto que está na classe correspondente ao comando, caso contrário mostra uma mensagem de erro.

Tela de seleção - Comando TASK

Explicação para o comando TASK - Classe LCL_TASK

Comando JUMP não existe

Resultado do comando JUMP

Programa ZABAP101_FACTORY_PATTERN completo.

A classe LCL_COMMAND é responsável por decidir de qual classe o objeto deve ser criado. Se ocorrer um erro na criação, ou seja, se a classe que estamos querendo criar o objeto não exista, uma exceção é lançada e tratada como um erro de sintaxe.

Repare que eu monto o nome da classe de acordo com o nome do comando entrado pelo usuário no parâmetro do programa. Ou seja, para esse caso, a classe do comando precisa seguir a seguinte nomenclatura: LCL_<comando>, caso contrário haverá um erro na criação do objeto daquela classe, pois a classe não existirá.

Os objetos dos comandos são criados no método FACTORY( ), com o seguinte comando:

CREATE OBJECT re_instance TYPE (lv_command).

O tipo do objeto é definido em tempo de execução, de acordo com o valor da variável lv_command. Colocando a variável entre parênteses, o interpretador ABAP entende que o tipo do objeto a ser criado não é lv_command, mas sim o que está no conteúdo da variável entre os parênteses.

Qual a Vantagem?

Por que criei uma classe para cada comando? Porque dessa forma, pode-se adicionar um novo comando de maneira MUITO fácil, apenas criando uma nova classe para o novo comando e herdando da classe LCL_COMMAND.

Todo o resto não será afetado.

(sim, isso cheira polimorfismo).

(sim, isso é genial!!!)

O padrão de projeto Factory pode ser implementado de várias maneiras, essa foi apenas uma delas. Acho sim interessante estudá-lo para ter mais essa ferramenta em sua workbench.

Estava procurando algum assunto para escrever, e uma luz do céu e-mail chegou com uma dúvida e que em todas as turmas da Academia ABAP tem, como importar ou exportar uma tabela interna para um módulo de função ou método.

A solução pode ser respondida com uma simples frase: “Use um Table Type (Categoria de Tipos)”. Só com isso já seria suficiente para você sair do outro lado, mas fazendo jus ao “101″ do nome do site, vou explicar passo a passo como fazer em um módulo de função. No próximo post, eu explicarei como fazer em um método.

Problema

Precisamos criar um módulo de função para retornar dados dos vôos (tabela SPFLI), dado uma empresa aérea.

Solução

A primeira coisa a fazer é criar um tipo tabela (table type) no dicionário, que define uma tabela interna do tipo standard. Vá na transação SE11 e escolha Data Type:

Clique em “Create” e escolha Table Type:

Entre com uma breve descrição e o Line Type, que define a as colunas na tabela interna. Nesse caso queremos todas as colunas da tabela SPFLI.

Certifique-se o tipo de tabela seja Standard Table.

Com o tipo global criado e ativo, vamos a criação ao módulo de função. Primeiro, é necessário criar uma Grupo de Função na transação SE80. Escolha “Function Group” e defina um nome. Pressione ENTER e confirme a criação do novo objeto.

Depois de criar o grupo, crie o módulo de função. Pressione o botão direito do mouse sobre o grupo de função, escolha Create -> Function Module.

Defina o nome a descrição para o módulo de função. O nome precisa necessariamente “Z_”.

Agora vamos definir o parâmetro de Import, IM_CARRID, com o mesmo tipo do campos CARRID da tabela SPFLI.

Para o parâmetro de EXPORT use o Table Type definido anteriormente.

Não vamos nos esquecer de definir as exceções, no nosso caso, defina apenas uma única exceção.

E para finalizar, entre o código abaixo:

Z_FM_GET_CONNECTIONS

Execução e Teste

Depois de ativar o módulo de função, você pode executar um teste unitário pressionando o F8. Entre a empresa aérea “AA”. Pressione F8 novamente para executar o módulo de função, retornando duas entradas da tabela SPFLI.   Agora usando efetivamente o módulo de função, crie um programa que chama a função e imprima o resultado na tela. ZABAP101_REPORT_CONNECTIONS

Discussão

O principal ponto a destacar aqui é o tipo criado na SE11, ZTT_SPFLI. Antigamente usava a pasta Tables do módulo de função, onde era somente preciso especificar a estrutura que o próprio sistema entendia que deveria ser criado uma tabela interna em tempo de execução. Não usamos essa técnica pois já está obsoleto e por regra não devemos criar novos programas com instruções ou técnicas definidas pela SAP como obsoletas.

É interessante o uso do módulo de função para seleção de dados, pois assim podemos reutilizar em outros programas. Esse módulo de função serve como Model (do nosso conhecido MVC). Podemos incluir ali outras regras de negócio que poderão ser facilmente reutilizadas em outros programas. Além disso, se essa regra mudar por qualquer motivo, não é necessário alterar vários programas, mas apenas dentro do módulo de função.

Quando eu explico tratamento de exceção na academia ABAP, o pessoal não dá muita bola, até porque os alunos ainda estão tentando se recuperar das aulas de polimorfismo e interface, mas entender o funcionamento dela é vital para desenvolver boas soluções usando orientação a objetos (não somente para aprender a escrever a palavra exceção).

Nesse post, vou explicar dois conceitos ligado ao tratamento de exceções baseado em classes, propagação e comando CLEANUP.

Começando Pelo Básico

Vamos entender primeiro o funcionamento básico do tratamento de exceções baseado em classes. Quando usamos as classes de exceção, devemos usar a estrutura de comandos TRY-CATCH-CLEANUP.

Usarei a classe LCL_EXCEPTION_DEMO que está no include ZABAP101_EXCEPTION_CLASSES nos programas de exemplo.

O primeiro programa que mostrarei é um programa cuja saída é … um DUMP!? Sim, quando o sistema chega a alguma situação onde ele não consegue seguir com o programa, como por exemplo uma divisão por zero.

Quando o programa tenta fazer uma divisão por zero a seguinte tela é mostrada. Toda a pilha de execução é eliminada e toda a memória usada pelo programa é apagada.

Mas graças ao tratamento de exceção por classes, você pode dizer para o sistema “tente executar essa operação, e se caso aconteça divisão por zero, execute isso”.

Nesse primeiro programa onde o DUMP é evitado, o método SIMPLE_CATCH( ) é chamado. Na implementação do método, ele tenta (TRY) executar uma divisão por zero, que é tratada (CATCH) dentro do próprio método.

Repare que a a exceção é tratada dentro do próprio método, portanto a mensagem “Executou o CATCH do método SIMPLE_CATCH.” é impressa no lugar do DUMP. A saída do programa acima é mostrada abaixo:

Propagação de Exceção

Conheço muitas equipes onde esse conceito é muito bem difundido, ou seja, uma pessoa decide não ser responsável pelo erro que cometeu e decide passar o erro para outra pessoa corrigir. Pois é, no ABAP temos algo parecido. Veja esse programa:

Quando o método PROPAGATING( ) é chamado, uma divisão por zero é executada. Observe que esta divisão não está sendo tratada com o TRY-CATCH e veja a saída do programa:

O segredo está na declaração do método: “METHODS propagating RAISING cx_sy_zerodivide.” Existe uma instrução RAISING que diz exatamente o que algumas pessoas que conheço fazem, “olha, pode ser que uma divisão por zero aconteça e se isso acontecer você [quem está chamando o método] deverá tratar essa exceção”.

Sendo assim, a exceção precisou ser tratada na chamada do método e não mais dentro do método.

Qual forma usar, a do primeiro programa ou essa? Depende. Se você quer passar a responsabilidade do tratamento para quem chama o método então o segundo programa deve ser usado. Mas se o erro é algo interno do método e precisa ser tratado de maneira transparente do usuário, então você deverá tratar a exceção dentro do próprio método, assim como fora feito no primeiro programa.

O que acontece se não tratarmos a exceção na chamada do método? Experimente…

CLEANUP não é WHEN OTHERS do Tratamento de Exceções

Essa é a primeira conclusão que os meus alunos chegam quando olham para definição do comando no Help do ABAP.

Não, o CLEANUP não é uma espécie de WHEN OTHERS do TRY-CATCH. Para ilustrar o uso do CLEANUP, veja o programa abaixo:

O objetivo do CLEANUP é para a limpeza de variáveis (memória) quando acontece uma exceção que será propagada. Seria o equivalente ao “quero limpar a bagunça antes de passar a exceção para ser tratada por quem chamou o método”. Pela saída do programa, você consegue entender a sequência de execução do programa. Ocorre a exceção, o CLEANUP é executado e então o CATCH no programa principal.

CLEANUP Morto

O CLEANUP somente é usado para “limpar a bagunça” quando a exceção está sendo propagada. No programa abaixo, o CLEANUP nunca será chamado.

Na saída do programa vemos claramente que o sistema não executou o CLEANUP, pois a divisão por zero é tratada dentro do próprio método.

Conclusão

Os conceitos de tratamento de exceção por classes não fica somente nisso, mas nesse post quis apenas expor os conceitos de propagação e CLEANUP. Para o uso correto de classes de exceções, é necessário entender encadeamento de exceções, hierarquia de exceções e textos da exceção. Isso será explorado em futuros posts.

Aprenda a usar corretamente as classes de exceções e você entregará programas muito elegantes e de fácil manutenção.

Semana passada, mais especificamento no dia 12 de Abril tive a oportunidade de participar do SAP Inside Track Vancouver 2012. Gostaria de compartilhar detalhes do evento já que este evento também ocorre no Brasil.

Para quem não sabe o SAP Inside Track é um evento aberto a comunidade e gratuito. Ano passado, participamos do evento realizado em São Paulo e em São Leopoldo. Nele são apresentados novas tecnologias, tendências de mercado, demonstrações de produtos e outras atividades bem interessantes. No caso do evento em Vancouver, o tema foi mobilidade. Como o número de vagas é limitado, não hesitei quando li na SDN o anúncio do evento, 2 meses antes do mesmo. Sugiro o mesmo caso queira participar do evento no Brasil. Por isso, fique sempre ligado na SDN e leia os newsletters.

Registro

Ao fazer o registro, recebi um ticket virtual no EventBrite em forma de QR Code. Para entrar no evento, bastei apenas mostrá-lo a partir do meu celular. A questão da mobilidade já estava presente antes de entrar no prédio da SAP, mostrado na imagem abaixo. Ainda na entrada foram distribuídas senhas para usar a rede wireless durante o evento, algo que seria muito importante.

Abertura e Quebra-Gelo

Como de praxe, durante a abertura do evento foi mencionada a nova SCN e a importância da mesma. Alguns números bem surpreendentes quanto a comunidade foram mostrados para demonstrar sua importância. Após isso houve uma atividade quebra-gelo que foi uma excelente oportunidade para fazer networking com os demais participantes. Foi nos dado uma espécie de cartela de bingo e canetas. Em cada quadrado da cartela havia uma afirmação referente a diversos assuntos (estilo de vida, esportes, vida profissional, hobbies, gostos etc). A atividade consistia em colecionar assinaturas dos participantes que tinham alguma das afirmações na cartela como verdade. Por exemplo, um dos quadrados continha a frase “Prefiro Pepsi a Coca-Cola”. Os primeiros a completar a cartela ganhariam algumas camisas, os primeiros prêmios dos muitos que foram distruibuídos. Após 30 minutos eu estava carregado de cartões de contato e tinha conversado não só com pessoas que trabalham na SAP, mas também com consultores, responsáveis em empresas sem fins lucrativos, estudantes etc. Esta com certeza uma das grandes vantagens de participar de qualquer tipo de evento: conhecer pessoas.

Palestras

As palestras (veja a lista na página da SCN sobre o SAP Inside Track Vancouver) foram bem voltadas ao mercado. Nada muito técnico foi abordado e siglas diversas foram distribuídas, algo que para alguém que não trabalha com mobile como eu, faz você se perder sobre o assunto. De toda maneira, as palestras foram dadas por pessoas que encabeçam assuntos relacionados com mobile dentro da SAP. Algo que merece destaque foi uma demonstração ao vivo do Afaria durante uma das palestras usando celulares dos participantes.

Demo Jam

O que para muitos é o ápice do evento, o Demo Jam foi marcado por muitos risos e descontração. Nele participantes (a maioria funcionário da SAP – apesar de ser aberto para qualquer um no evento) demonstraram seu trabalho usando tecnologias relacionadas com mobile. Foi interessante ver que um dos participantes que não tem formação em TI e não trabalha em um departamento técnico apresentou um trabalho bem interessante para localizar bebedouros em Vancouver usando o GPS. Cada um teve 5 minutos para apresentar seu trabalho e no final a votação para decidir o vencedor foi realizada pelo público, para variar, usando celulares e smartphones. O vencedor tinha que escolher seu prêmio entre um blackberry ou um playbook.

Prêmios e Brindes

No fim, uma grande quantidade de brindes foi sorteada. Todos os brindes tinham uma relação com mobile indo desde a ipod nanos e shuffes até luvas especiais para usar telas touch screen. Fui sorteado e acabei ganhando um case para playbook.

Patrocínio + Desconto

O evento foi patrocinado pela SAP Press. Foram distribuídos panfletos que continham cupons de 10% desconto para livros na SAP Press validos até o dia 30 de Abril. Você também pode utilizar o cupon para a compra de qualquer livro na SAP Press. Para isso basta apenas usar o código SITVAN12 ao fazer checkout da sua compra.

Participe!

Reforço a importância e os benefícios do evento. Se você tiver a oportunidade de participar de um evento como o SAP Inside Track, não fique de fora.

Veja algumas fotos do evento aqui.

O que é um programa ABAP orientado a objetos? Se um programa usa somente CALL METHOD e nenhum PERFORM, então trata-se de um programa orientado a objetos? Acredito que não.

O uso de sintaxe de orientação a objetos não é evidência suficiente de que o programa foi pensado na forma de objetos trocando mensagens entre si.

Trago para vocês dois pogramas com saídas idênticas, mas um usando uma “orientação a objetos” capenga e outro que considero uma melhor forma de resolver o problema pensando em objetos.

O Requisito

Relatório de impressão de pedidos, com um total e a porcentagem de cada item em relação ao total do pedido. Os itens do pedido foram criados no próprio programa por uma questão prática e didática. No mundo real esses dados estariam armazenados numa tabela no banco de dados.

Orientação a Objetos “para inglês ver”

A listagem abaixo é a solução usando orientação a objetos incompleta, ou seja, o programa tem uma classe para os objetos que representam itens do pedido. Cada objeto é um item do pedido, mas ainda tem alguns problemas.

ZFAKE_OO

Qual o problema com esse programa? Minha crítica a esse programa é a presença de regras de negócio no programa principal. É no programa principal que o cálculo do total do pedido é feito bem como o cálculo do percentual de cada item em relação ao pedido total. Se seguirmos o padrão MVC, esses cálculos deveriam estar encapsulados em alguma classe, fazendo o papel do Modelo. É exatamente isso que o próxima solução leva em conta na hora de refatorar o código.

Refatorando Para Melhorar o Código

Refatoração é um conceito no desenvolvimento de software onde melhoramos o projeto de software sem alterar os requistos do mesmo. Ou seja, vou alterar o programa para que a solução fique mais robusta, elegante, melhorando a legibilidade e possibilitando o reuso. Nessa primeira rodada de refatoração, eu procurei encapsular todos os cálculos em classes, para que possam ser reutilizadas em futuros desenvolvimentos. Repare que eu criei uma nova classe onde os cálculos são executados e o próprio relatório é impresso.

ZBETTER_OO

Próximos Passos

Esse é a melhor implementação? Com certeza não. Escolhi não aplicar o MVC de maneira forte para dar chances para vocês pensarem em outras melhorias possíveis nesse programa.

O que vocês fariam? Deixem nos comentários quais melhorias vocês fariam nos dois programas.

Boa diversão!

Saídas dos Dois Programas Acima

Então você já aprendeu como declarar uma classe, chamar um método e aplicar os conceitos de herança e polimorfismo (já né?). Parabéns você completou a primeira parte do aprendizado em programação orientada a objetos. Agora só falta mais uns 95% para poder ser considerado um Mestre Jedi em Orientação a Objetos.

Vamos ganhar mais um ponto porcentual e falarmos de Singleton.

Singleton é um Padrão de Projeto (ou do inglês Design Patern). Os padrões de projetos tem como objetivo o reuso do projeto (não de código). É o reuso de uma solução para um problema simples e comum dentro da programação orientada a objetos.

O problema do Singleton resolve é muito simples: criar uma classe que permita uma e somente uma instância da classe em questão.

Vamos discutir abaixo a solução clássica em ABAP.

Gist: https://gist.github.com/2174007

Descrevendo a Classe

A classe em que será aplicada o Singleton é a LCL_HELLO_SINGLETON. Vamos começar com a declaração dela pois ela já nos trás algumas novidades:

CLASS lcl_hello_singleton DEFINITION FINAL CREATE PRIVATE.

A classe precisa necessariamente ser final, ou seja, ela não aceitará que nenhuma outra classe herde dela. Não é possível criar uma subclass da LCL_HELLO_SINGLETON, pois isso seria uma brecha onde o usuário criaria uma subclasse e que não respeitaria a regra de não permitir mais de uma instância dela.

A classe LCL_HELLO_SINGLETON também deve ter a sua regra de instanciação como privada. Isso significa que um objeto dessa classe somente pode ser criado dentro dela mesma. Isso garante o controle da criação dos objetos seja somente dela mesma. Nossa pequena classe é dona de seu próprio destino.

A segunda característica dessa classe é a presença de um construtor estático (método CLASS_CONSTRUCTOR). Um construtor estático é chamado apenas uma única vez durante toda a vida da classe. Ele difere do construtor da instância (método CONSTRUCTOR – não usado nesse exemplo) por ser chamado apenas uma única vez quando a classe é usada pela primeira vez (seja na criação de um objeto ou na chamada de um método estático – usado no exemplo). Um construtor de instância é chamado no momento da criação do objeto com o comando CREATE OBJECT.

O método estático GET_INSTANCE( ) é usado para retornar o valor que está no atributo estático R_INSTANCE, que é a referência do único objeto criado para essa classe.

O único objeto a existir para a classe LCL_HELLO_SINGLETON é criado no construtor estático e a sua referência é o R_INSTANCE.

Os métodos SET( ) e GET( ) são os chamados métodos de acessores, que servem para definir e retornar os atributos da classe, respectivamente.

Executando o Programa

Ao executar o programa, precisamos chamar o método estático GET_INSTANCE( ) para que a classe nos retorne a referência do objeto que ela mesma criou e está gerenciando. Mas nesse instante o objeto ainda não fora criado?! Erro na implementação do Padrão de Projeto!!! Calma…

A criação do objeto está no construtor estático que será chamado apenas uma única vez, quando a classe for usada. Sendo assim, quando chamarmos o método GET_INSTANCE( ) o construtor estático é chamado primeiro criando o objeto a ser retornado pelo parâmetro RE_INSTANCE( ). Genial? Não, programação orientada a objetos.

Agora todas as vezes que o programa precisar usar recuperar a referência do objeto filho único, ele deve chamar o método GET_INSTANCE( ).

Conclusão

Quando devemos usar um Singleton? A resposta é simples, economia de memória. Fato que um mesmo volume de dados representado em objetos pode consumir mais memória do que o seu equivalente em procedural, para uma boa ilustração disso, veja o post onde o Fábio fez uma comparação de consumo de memória entre uma tabela interna e os mesmos dados dessa tabela interna usando um objeto para cada linha da tabela.

Em geral, um programa ABAP manipulará os dados de duas maneiras, um Objeto de Negócio por vez, ou um conjunto de objetos por vez.

Em nossa vida de programador ABAP não é lá muito comum trabalharmos um objeto de negócio por vez, pois os programas standard já fazem isso. Geralmente trabalhamos um registro por vez quando estamos desenvolvendo algum module pool e os modules pools mais legais já foram feitos pela SAP.

A Claudia já comentou isso e é verdade, a maioria dos nossos programas são relatórios. E quando trabalharmos com relatórios invariavelmente seguimos a sequência, tela de seleção – seleção de dados – tratamento dos dados – apresentação dos dados. Então, quando estamos tratando os dados fazemos um LOOP AT na tabela interna e para cada registro a ser tratado usamos as regras de negócio encapsuladas nos métodos dessa classe. Portanto, não precisamos de todos os objetos criados ao mesmo tempo, apenas uma instância de nossa classe, sendo atualizada para cada registro a ser tratado.