Falsa Programação Orientada a Objetos
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.
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.
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
Excelente post!
Sempre tenho dúvida de como implementar reports mais simples utilizando o máximo possível OO.
Como vc disse, há várias maneiras de tentar modularizar programas OO seguindo o modelo MVC, eu geralmete crio um include com as classes de regra de negócio tenho meio receio se sair criando para programas pequenas classes globais na SE24. Mas o que deixa ainda “locais” as classes. O que vcs acham sobre isso, é melhor manter elas locais ou não vêem problema em criar elas globais, ou, ainda, já que ela é local é melhor manter as classes no próprio report?
Valeu!
(ah, acho q os códigos estão invertidos, o primeiro é o better e o segundo é o fake).
Olá Flávio, Gostei do seu Post. Concordo com você, trocar perform por methods não significa que estamos utilizando OO. Precisamos entrar no mundo da Orientação, utilizando por exemplo MVC.
Neste exemplo. Criaria um method para adicionar o produto, sempre que um item fosse inserido, atualizaria o total do pedido.
Parabens!!!
Concordo, isso deixaria a classe mais flexível. Você entendeu bem o conceito!
Abraços!
Eu acho que os códigos estão trocados =P
De qualquer maneira, o programa como está pode ser reutilizado, pode-se re-implementar a classe que imprime o relatório para deixar mais genérico e dependendo do layout requisitado, pode-se criar objetos diferentes e usar polimorfismo para a impressão.
Só idéias de um abap newbie=P.
abraços professor!
Olá Adriano,
Gostei da sua idéia. Estou pensando em uma possível solução para publicar aqui. Se você tiver alguma outra idéia, pode me mandar um e-mail.
Abraços!
Excelente post!!
Eu confesso que não sou fã da Orientação a Objetos, eu consigo pensar melhor e fazer algo mais rápido(porque tudo o que o cliente quer é prioridade e para ontem) eu utilizo a programação estruturada, mas o que eu tenho mais raiva em ver em codificação alheia (principalmente quando vou fazer alguma manutenção) é essa falsa orientação a objetos! Tudo que a pessoa faz é chamar um método ao invés de um perform/call function!
Aí eu penso, não seria mais fácil, se não houver reusabilidade de nenhuma classe/método, fazer um programa estruturado do que com essa falsa orientação a objetos?
Entendo a sua frustração e também pensava dessa forma, mas se você não programar OO nunca, você nunca ficará fluente.
OO é treino, quando mais você programa, melhor seus programas OO ficarão.
Ótimo exemplo para ficar um tempo estudando mais sobre OO.
Obs.: Faltou apenas no exemplo do “Z_BETTER_OO” chamar o método display_report() para exibir os itens.
Abs.
Bom dia, gostaria de fazer uma pergunta. No exemplo acima você colocou os types fora das classes. Eles não poderia ser declarados em uma classe, e depois usados em outra? Sempre tenho essa duvida. Acabo declarando o TYPE fora também por que nao consigo usar um type de uma classe em outra sem ser por herança.
Bom dia,
Recentemente vi este post post no Twitter e fiquei muito curioso com o titulo, após ler a matéria venho discordar veementemente da mesma, pois Abap é uma linguagem híbrida e toda sua arquitetura OO foi baseada em linguagens híbridas como Java e C++, segundo a própria SAP :
http://help.sap.com/saphelp_nw04/helpdata/en/c3/225b5354f411d194a60000e8353423/content.htm
Não existe conceito de falsa orientação a objeto, e nada impede de usar um procedimento (procedure) para trabalhar com um objeto instanciado de uma classe, alias isto é utilizado e é ensinado pela própria SAP em vários programas de demonstração da empresa.
Segue demo do NetWeaveaver 7.x
programa de demonstração da SAP:
SAPSIMPLE_TREE_MODEL_DEMO
Include:
SIMPLE_TREE_MODEL_DEMOF01
obrigado.
Ronaldo,
O post não fala sobre a capacidade de misturar métodos e rotinas. O post fala sobre a ideia de que usar a sintaxe de orientação a objetos não significa pensar no seu programa orientado a objetos. O termo “falsa orientação a objetos” não é um conceito mas sim uma ideia, uma opinião e que eu assino em baixo.
Já escrevi muita classe que serve simplesmente para encapsular uma BAPI ou um comando CALL Transaction ou até a formatação de um ALV. Não há nada de errado com isso.
O problema em questão é se codificar uma aplicação usando *uma* classe com *um* método e instanciando *um* objeto e dizer que usou-se orientação a objetos. A sintaxe OO não leva a uma arquitetura OO.
Att,
Ola,
Cara, eu concordo com o Ronaldo, Abap é uma linguagem híbrida e multi paradigmas como varias outras, pelo conceito do seu post, usar um tipo inteiro que é um tipo primitivo e não um objeto, dentro de uma classe eu não estou pensando na Arquitetura OO.
Assim como C++ uma void fora de uma classe é a mesma dentro de uma classe, nada te impede de criar uma void comum para criar varios objetos ou alimentar uma coleção de objetos em determinada circunstância, do mesmo modo como o Perform em Abap. Especialmente que classes em C++ que são padronizadas em dois arquivos o .h (classe e interface) e o .cpp (implementação).
“A sintaxe OO não leva a uma arquitetura OO” ?
Utilizando um framework de objetos com classes já prontas e instância-las sem criar nenhuma nova classe para criar um algoritmo eu não estou usando arquitetura OO?
De varias linguagens OO, apenas o C# e Java te obrigam a usar uma classe para criar um algoritmo, todas as outras não, especialmente Ruby que é uma linguagem puramente orientada a objeto e um inteiro em Ruby é um objeto e não um primitivo, e não preciso estar dentro de uma classe para programar OO, tudo é OO.
Para mim a única coisa que vejo nos códigos acima é que a primeira classe é muito mal feita.
Pela sua “ideia” de falsa orientação a objeto, eu poderia ir mais longe e assinar em baixo, que apenas Java e C# é verdadeira programação orientada a objeto, pois esta tudo dentro de classes, e nem o seu código Abap esta!
OO é capacidade de instanciar objetos, então a sintaxe OO leva sim a uma arquitetura OO.