Hello World Orientado a Objetos
Uma coisa que não mais iremos discutir aqui no ABAP101 é usar ou não programação orientada a objetos, por isso estamos abolindo procedural do ABAP101, caso você veja alguma coisa procedural aqui no site, por favor avise-me!
Programação procedural pode parecer mais fácil, mas é porque estamos mais acostumados com esse tipo de programação do que orientada a objetos. Tome uma resolução em sua vida ABAPer, faça tudo em ABAP OO, mesmo um simples relatório. Comece com uma simples classe e daí vá evoluindo, mas fuja da “primeira dose” do procedural. Acredite a vida é bem melhor sem procedural!
A orientação a objetos nos permite abstrações muito mais elegantes do que a procedural sendo os programas orientados a objetos muito mais fáceis de fazer manutenção, permitindo reuso real e muitas outras coisas que somente usando no dia-a-dia podemos perceber.
Pensando nisso, criei esse post onde mostro uma série de versões do famoso programa Hello World orientados a objetos. A primeira vez que o programa Hello World em ABAP apareceu por aqui foi em 2007, nesse post aqui. A solução vai crescendo mostrando algumas formas de abstração resolvendo o mesmo problema de várias maneiras possíveis.
Primeira Versão
Nessa versão temos uma classe chamada LCL_HELLO com apenas um único método DISPLAY_MESSAGE( ).
Nessa versão contém apenas uma única classe com um único método. Não temos muito de programação orientada a objetos aqui, mas já estamos deixando a sementinha do OO entrar em nossos programas.
Procedural Orientado a Objetos
Vamos adicionar um parameter em nosso programa e começar a discutir algumas opções de abstração. A primeira opção eu chamo de “Procedural Orientado a Objetos”. Aqui não estamos pensando numa solução orientada a objetos, mas pensando em procedural.
Veja que poderíamos substituir perfeitamente por um FORM/PERFORM sem grandes mudanças na abstração, mas lembre-se que queremos evitá-los de qualquer maneira, mesmo assim essa versão é muito melhor que qualquer outra versão procedural.
Melhorando a Impressão da Mensagem
Uma verão mais interessante que eu proporia seria a mostrada abaixo:
O resultado é o mesmo, mas agora temos um objeto LCL_HELLO que recebe um nome para saudação na sua construção e daí mostra a mensagem pelo método DISPLAY_MESSAGE( ). Já conseguiu imaginar um objeto que tem a responsabilidade de mostrar uma mensagem na tela?
Permitindo Operações No Objeto LCL_HELLO
Ainda sim não estou contente com a solução. E se quisermos alterar o atributo NAME antes de mostrarmos a mensagem? E se quisermos saber o atributo NAME antes de mostrar para o usuário? Por isso é aconselhável criamos os métodos de acesso, os famosos SET e GET. Veja como ficaria nosso programa:
Pense que agora temos um objeto HELLO no qual podemos alterar seu estado (SET e GET) quantas vezes quisermos. A abstração está muito melhor agora, mas dá para melhorar ainda mais!
MVC no Hello World, Pode?
Que história é essa do programa principal verificar se a mensagem é correta ou não!? Esse programa deveria cuidar apenas em receber a entrada do usuário e chamar o objeto para mostrar a mensagem. Não deveria ter nenhuma regra (de negócio). Essa verificação deveria estar no modelo, ou seja, classe LCL_HELLO. Então, vamos melhorar ainda mais o nossa classe:
Mesmo que algum Perform Fanboy invada seu programa na calada da noite, você já contará com uma certa proteção dentro do seu programa contra maus programadores terá protegido seu programa (já que ele não saberia alterar a classe :-p ). Além do mais, você também terá o conceito de encapsulamento aplicado aqui. Repare que a regra de não permitir o parâmetro NAME como “procedural !!” está agora embutido no método SET( ). Isso impede que o atributo seja alterado indevidamente por qualquer outro programador mal comportado que venha dar manutenção em seu código. Ou seja, podemos alterar quantas vezes quisermos o atributo NAME, mas seguindo a regra definida no método SET( ). Mas será que daria para melhorar ainda ainda mais? Resposta é sim!
Versão Final! (Será?)
Agora sim, temos uma separação bem definida entre quem é responsável por tratar com o usuário (programa principal, com PARAMETERS e WRITE) e quem cuidará das regras do texto (classe LCL_HELLO). Ainda sim, estaremos protegidos do Performa Fanboy e deixamos nosso programa reutilizável.
Quando você começa a usar programação orientada a objetos você naturalmente começa a pensar nesses conceitos, como robustes, facilidade de manutenção, encapsulamento
Como regra prática, procure deixa comandos WRITEs fora das classes de negócio (Model).
Conclusão
Podemos ver que um simples problema de impressão do Hello World!! pode ganhar diversas soluções. Enquanto estou escrevendo esse parágrafo, já pensei mais outras duas. Isso prova que em programação orientada a objetos não existe certo ou errado, existe sim um equilíbrio, um balanço de quanto de reuso, abstração ou encapsulamento você quer aplicar ao seu problema. Isso dependerá muito de caso para caso. Mesmo assim não importa, continue programando somente em OO, acredite, um dia você irá me agradecer por isso.
Será que essa é a versão final? Será que você ficou contente com apenas 6 versões? E aquelas duas que eu pensei, como seriam? Deixe sua versão do Hello World OO nos comentários. Estou muito curioso em saber como você resolveria o Hello World!! além do
WRITE: ‘Hello World!!’.
Furlan, parabéns pelo post.
Muito bom para “abrir” a cabeça de nós Abapeiros para essa nova forma de programar.
Sem dúvida, muito melhor com OO.
Putabração,
NORBERTO SILVA
Também recorro muito a OO mas tenho uma visão menos radical. Julgo que não tem mal misturar procedural (ou funcional) com OO e para mim um bom exemplo disso é Python, que tem uma biblioteca muito OO mas também usam funções quando estas fazem mais sentido. Mas não me interpretem mal, para mim OO é bom.
Agora o ponto em ABAP OO que gostaria de colocar em questão é sobre usar classes locais como nestes exemplos, ou classes globais na SE24. A minha experiência é que as classes locais permitem melhor manutenção pois é possível ver todo o código de um ou vários objectos no editor. Quando as classes usam a SE24 é necessário muita navegação entre métodos do objecto, o que faz com que o código fique um pouco escondido e isso dificulta ler, editar e identificar bugs. E talvez por isso às vezes os objectos na SE24 acabam por ter poucos métodos e muita lógica em cada método o não é a melhor prática em OO.
O que acham sobre objectos locais e globais?
Abraço,
Pedro Lima
Olá Pedro,
Concordo com você sobre a SE24. Inclusive, nos projetos do ABAP101 e nas academias que eu leciono, eu aconselho criar primeiro o programa em classes locais e depois exportar para globais.
O que me deixa mais animado é que a própria SAP já percebeu esse problema e na nova versão do “MiniSAP” que está disponível no SCN tem uma funcionalidade que permite a edição da classe local no formato formulário (tradicional que já conhecemos) e formato Code-based, similar à edição das classes locais. Eu já testei e funciona muito bem.
Abraços!
Furlan
Não sabia dessa funcionalidade. Sem dúvida uma melhoria importante e que espero vir a usar em breve.
Abraço, Pedro
Furlan, por gentileza você pode disponibilizar o link do SCN para baixar o novo MiniSAP?
O link é http://scn.sap.com, procure pelo link Downloads e procure por SAP Netweaver Application Server Trial.
Abs!
Bom dia Furlan,
Comecei recentemente como estagiario na empresa e tive a oportunidade de conhecer o ABAP e utiliza-lo.
No entanto, na empresa ainda é utilizado a forma procedural e não a OO.
Gostaria de saber se é melhor eu ja ir pagando o jeito em OO levando em consideração que, estou realmente cru na linguagem, ou focar os estudos em estrutural?
Se possivel voce poderia me indicar alguns links ou me passar algum material para que eu tenha um passo a passo de como programar em ABAP?
Por exemplo:
Nos programas “Hello Wolrd” citados acima devemos pensar cada novo programa como uma nova classe?
Como executamos o programa? Criei o programa abaixo na SE38, no entando não houve execução. Comecei apenas copiando e colando o exemplo para tentar entender o funcionamento, voce poderia me informar o que eu fiz de errado?
REPORT ZPTREINADFA_OO_01 NO STANDARD PAGE HEADING.
CLASS lcl_hello DEFINITION. PUBLIC SECTION.
METHODS: display_message.
ENDCLASS.
CLASS lcl_hello IMPLEMENTATION.
METHOD display_message.
WRITE: / ‘Hello World OO!’.
ENDMETHOD.
ENDCLASS.
Tenho uma certa experiencia com processo de OO mas não conheço a ferramenta ainda.
Por isso me desculpe por tantas perguntas.
Grato,
David Araujo.
Em Java e Ruby por exemplo os programadores já aprendem usando OO.
Em ABAP seria se fosse OO desde o inicio, mas não vejo grandes problemas , já que você esta apenas começando.
Se você não provar nada em procedural, ninguém te escutará quando você falar de OO.
AChei que iria encontrar aqui algo simples para iniciantes, mas vejo que estou errado!
Acho que deveria ter mais exemplos em procedural.
Olá Ricardo,
Os exemplos dados foram realmente muito simples, como todo Hello World!
Nossa missão é ajudar quem quer ser um bom profissional e um dos pilares é usar as melhores práticas (inclusive recomendadas pela SAP) mesmo para quem está começando. O quanto antes você se habituar com OO melhor.
Além do mais, não caberia um exemplo procedural em um post sobre Orientação a Objetos.
Abraços!
Boa tarde Furlan,
Os exemplos acima me ajudaram a entender melhor o conceito de OO em ABAP, e tentei criar uma classe para fazer as operações matemáticas simples. A partir daí, fiquei com a seguinte dúvida: A validação do parameter responsável por receber o operador deve ser feita através do “AT SELECTION-SCREEN ON “, ou é mais aconselhável que a classe execute essa validação.
Obrigado,
Pedro.
Olá Pedro,
Boa pergunta, como a validação é uma “regra de negócio” deve ficar na classe, mas aí você perderia a funcionalidade do AT SELECTION-SCREEN.
O que você pode fazer é colocar um método estático para validação das operações e chamá-lo no evento AT SELECTION-SCREEN.
Abs!
Fulan, td bem?
Obrigado pela resposta.
Abraço.