Você ainda não sabe programar ABAP OO?

Se você não é um completo alienado no mundo ABAP, já deve ter ouvido falar sobre o tal do ABAP OO, ou seja, ABAP Orientado a Objetos. Esse assunto é estratégico para a SAP e é forma de programação que ele recomenda, tanto que é uma das partes mais pesadas na certificação ABAP.

Nesse post aqui vou mostrar as vantagens desse paradigma de programação e como ele pode te ajudar a criar programas mais robustos e de fácil manutenção.

Conceitos Iniciais

A primeira coisa que você precisa entender é que a ABAP OO não é somente trocar PERFORMs e CALL FUNCTIONs por CALL METHODs. Você até pode fazer um paralelo, mas as semelhanças conceituais são enormes.

A programação orientada a objetos (OOP) é uma forma de resolver um problema, assim como procedural, programação por aspectos etc. Ela é totalmente diferente da procedural, pois não mais pensamos no programa como uma sequência de procedimentos, mas olhamos para o problema em si e pensamos em objetos se relacionando entre si, assim como acontece no mundo real.

No mundo real, temos objetos se relacionando a todo momento. Daí a grande vantagem da OOP versus a procedural. Os objetos do mundo real serão os mesmos que estarão representados no seu programa. Para exemplificar, não vou usar os exemplos clássicos das aulas de OOP (bicicleta, carro, pessoa etc.), mas vamos usar um exemplo real que você usará, uma Invoice.

INVOICE ou PROFORMA é um documento onde constam o valor da venda, a forma e data de embarque, é uma espécie de pré venda.

Veja um exemplo de documento de invoice:

Exemplo de Invoice - Transformers

Esta invoice no SAP fica com essa cara (não é a mesma invoice dos Transformers):

Exemplo de Invoice no SAP

Quando estamos nos referindo a uma invoice em específico, a primeira coisa nos vem a cabeça são os dados dessa invoice, como por exemplo, quem vende (Autobots) e quem deve pagar (Decepticons) e o que deve ser pago (itens da invoice). Essas são características presentes em todas as invoices.

Mas como esse invoice foi criada no sistema? Se eu precisar alterá-la? Ou apaga-la? E quando ela for paga, preciso alterar alguma coisa nessa invoice? Essas são ações aplicáveis a qualquer invoice.

Então as invoices possuem características e ações que podem ser descritas de maneira universal. Isso é feito pelas classes. Pense nas classes como moldes que descrevem como as invoices devem ser criadas. As classes representam como as invoices devem se comportar (chamados de métodos) e quais características (chamados atributos) devem ter. Podemos dizer, que são nas classes que definidos as regras de negócio que regem como as invoices devem ser.

Classe Invoice

Pegando o exemplo da invoice, ela pode ser representada em uma classe em ABAP da seguinte maneira. Eu estou usando a tabela transparente SNVOICE que faz parte do Flight Model Data.

ZCL_INVOICE e Seus Métodos

Nos métodos é que colocamos as regras de negócio, ou seja, as validações para que as invoices sejam criadas corretamente ou regras que garantam que elas não sejam alteradas incorretamente. Isso porque os dados em OOP estão encapsulados nas classes, ou seja, os dados só podem ser alterados mediante certas regras definidas nos métodos.

Não é o objetivo desse post descrever a sintaxe da criação de classes em ABAP e suas particularidades, mas apenas mostrar a orientação a objetos na programação ABAP.

No método SAVE( ) geralmente colocamos a chamada da BAPI que encapsula todas as regras de validação e verificação standard. Na classe colocamos somente as regras específicas para a solução do problema do cliente.

Nota: As regras aqui descritas estão extremamente simplificadas. A BAPI usada aqui foi criada apenas para ilustrar o conceito.

Usando a Classe Invoice

Para usar a classe ZCL_INVOICE eu criei um novo programa que usa os métodos da classe. Esse programa lista todas as reservas conforme a tela de seleção e quando o usuário dá o duplo clique numa reserva, a invoice é gerada automaticamente.

Conclusão

A programação orientada a objetos facilita o entendimento do problema e nos ajuda a construir programas mais robustos. Além do mais, nos permite criar artefatos de software reutilizáveis economizando tempo e dinheiro.

O aprendizado das técnicas orientadas a objeto é trabalhosa e demanda tempo para entender as diversas características. Mas é um tempo que vale a pena gastar e o mercado ABAP está cada vez mais valorizando isso.

You may also like...

9 Responses

  1. Rodrigo says:

    Olá, sou ABAP há 4 anos e acho muito interessante a parte de ABAP OO. Porém ainda não vi uma real utilidade deste método de programação no dia-a-dia. Este tipo de programação é muito válida em projetos de implementação e que há uma equipe abap rigorosa na empresa para a aplicação deste tipo de codificação e para que os processos reutilizem as classes. No dia-a-dia geralmente vamos construir uma solução específica tipo um relatório, uma interface, uma exit e não vejo razão nenhuma em utilizar OO nesses casos. Gostaria de ver uma matéria com exemplos de aplicabilidade real no dia-a-dia. No exemplo acima, supondo que eu tenha que desenvolver um novo programa para a criação das invoice, eu teria que criar toda a classe de invoice e depois criar o programa. Dificilmente um outro desenvolvimento irá utilizar a classe que eu criei, primeiro porque não é regra da empresa a utilização de OO e segundo que não conheço ninguém que fique procurando classes para utilizar no seu código, cada um codifica o seu e pronto. Com isso não vejo o porquê criar a classe se posso estruturar toda a lógica no programa. Enquanto não houver reais motivos para a utilização, acho difícil esse tipo de programação ser difundida. Exemplo claro e objetivo: por que num ALV eu usaria abap OO ao invés das funções REUSE_ALV*? É tão mais simples e objetivo usar funções e lógica procedural: cria o fieldcat e chama a função de exibição. Pronto! Nada de criação de tela com container, etc, etc.

    • furlan says:

      Olá!

      Programar usando OO realmente precisa de uma mentalidade para o reuso, mas se a empresa que você está não usa, por que não começar com você? Se você cair em um projeto onde a OO é obrigatória, como você se viraria? No caso da invoice do texto, você realmente não enxergou o reuso alí? O exemplo está simplificado para efeitos didáticos, mas se fosse um caso real deveríamos colocar todas os atributos da Invoice. Se você tiver que trabalhar com uma invoice em vários desenvolvimentos, você repetiria o código em todos os programas?

      A programação OO não é para resolver um problema que você tem agora, mas, se bem utilizada, poderá fazer com que futuros desenvolvimentos fiquem mais rápidos e mais baratos. Cito para você um caso de uma classe para processamento e tratamento de Batch Input. A criação da classe deu um pouco de trabalho para chegar no grau de reuso que eu queria (até porque não tinha muita experiência em OO), mas depois de pronta, os programas que eu precisei fazer usando BI foram entregues um pouco mais rápido, pois já tinha boa parte pronta. Ah, nessa empresa que eu implementei isso, não obrigava a fazer OO, eu fiz para aprender 😉

      Agora, vamos para a REUSE_ALV*. Você já precisou fazer algum aplicativo com 2 Grids na tela? E um Tree e outro Grid? E 4 Grids? Tente usar a função nesses casos.

      Abraços!

  2. Fábio Pagoti says:

    Oi Rodrigo,

    Como seu comentário foi bem extenso eu vou querer adicionar meus comentários também.

    Existem N threads no fórum da SDN solicitando exemplos reais do dia a dia para que se prove que orientação a objetos é mais interessante. Neste post temos um exemplo. Porém a maior prova que você pode ter é você mesmo tentar usar orientação a objetos. Com a prática isso se torna cada vez mais claro. Caso você apenas leia o post e não tente aplicar o conceito atrás do exemplo, provavelmente você apenas enxergará uma outra forma de se resolver um problema.

    A reutilização é apenas UMA das vantagens que a orientação a objetos pode prover ***se bem feita***. Como o Furlan disse, a manutenibilidade é outro motivo para aplicar OO. Podemos citar velocidade de desenvolvimento, robustez e flexibilidade como outros pontos.

    Se a empresa que você trabalha não obriga a utilização de orientação a objetos, temos as seguintes possibilidades (no meu ponto de vista): Ou ela tem conhecimento das vantagens de OO mas não tem profissionais preparados – e neste caso está errada em não preparar os seus profissionais sabendo dos benefícios OU ela não enxerga os benefícios e por isso não incentiva o seu uso – neste caso ela está errada e negligente também pois não é o ABAP101 que diz que OO é legal, é a comunidade global de desenvolvimento de software. Isso já deixou de ser opinião há tempos. Hoje é fato.

    Concordo e muito quando você diz que ninguém sai caçando classes existente para ver se pode ser reutilizadas. Porém este problema também acontece se você criar funções e também acontece para objetos do dicionário. Logo, o problema não é OO mas sim documentação. Melhor dizendo, o problema geralmente não está na documentação, mas sim na falta dela. Por exemplo em Java é disponibilizada a documentação das principais APIs separadas por pacotes no próprio site da Oracle, o famoso Javadoc (http://download.oracle.com/javase/6/docs/api/).

    Reforçando o mais importante da minha resposta: use OO para sentir os seus benefícios. Esta é a melhor forma de lhe abrir os olhos.

    Grande abraço!

  3. Ahm, Rodrigo, vc já utiliza OO no seu dia-a-dia 🙂

    A REUSE_ALV por dentro chama a classe de ALV e infelizmente, a função foi criada somente para suprir as pessoas que não entendem orientação à objetos.

    Você utiliza OO em BADIs e qualquer outra coisa do Enhancement Framework, várias exists de Função que são disparadas de dentro de eventos, nas verificações do Code Inspector, em proxys do PI, nas telas de WebDynpro, em quase qualquer coisa dentro do CRM e SRM, em Portal… ahm, acho que em praticamente tudo.

    A questão é: você realmente entende o que acontece no SAP quando você está trabalhando? Você entender os SET HANDLERs perdidos no código Standard?

    Aprender OO, não quer dizer só aprender a usufruir de todos os benefícios e técnicas: quer dizer que você também vai entender melhor o sistema no qual você trabalha todos os dias.

    Abraços!

  4. Custodio says:

    Discordo do Fabio onde diz que eh “fato” que OO eh melhor que procedural. Ha muitos estudiosos respeitaveis (Alexander Stepanov, Robert Harper, entre outros) que criticam OO.

    Assim como o Rodrigo eu entendo que para reports nem sempre OO eh a melhor opcao. Um exemplo: supondo que meu report utilize apenas um campo de um objeto X. O metodo x->get_instance( ) pode me retornar muito mais dados do que eu preciso, fazendo para isso muito mais acessos ao DB que eu preciso, prejudicando a performance. Um exemplo bobo, mas valido.

    Isto posto quero dizer que sou adepto de ABAP OO desde 2006, apenas nao sou xiita.

    Abraco,
    Custodio

  5. Fábio Pagoti says:

    Olá Custódio.
    Sinceramente desconheço tais fontes. Poderia compartilhá-las por favor?
    Eu não disse que OO é perfeito, disse que é melhor que procedural pois particularmente não encaro ambos paradigmas como opostos, mas sim OO como uma evolução do procedural.
    Não entendi muito bem o seu exemplo e porque usar OO poderia ser prejudicial.
    Uma das desvantagens que vejo em ABAP para usar OO é a sua sintaxe, que realmente é muito ruim mas não deveria servir de motivo para a sua não utilização.
    Abraços!

  6. Mário says:

    Bom dia!
    Qual livro de ABAP orientado a objetos vocês recomendam? Qual o melhor para um iniciante no mundo SAP (ABAP) e com pouquíssimos conhecimentos em OO?
    Desde já agradeço!
    Abraços

  1. September 8, 2011

    […] Esta apresentação é um excente acompanhamento para esse post aqui. […]