"
Apoiado por

Se ainda não usas ABAP Objects és mariquinhas pé-de-salsa

A SAP tem um livro chamado Official ABAP Programming Guidelines que descreve regras e boas práticas de como programar em ABAP. E lá diz assim (dizia em estrangeiro, eu traduzi):

Pág. 42: Regra 3.1: Usa ABAP Objects sempre que possível para novos desenvolvimentos. Só podes criar blocos de processamento clássicos em casos excepcionais.

Pág. 45: Num bloco de processamento clássico, deverás delegar imediatamente a execução para um método apropriado (ver Regra 6.37, Não implementes código em Módulos de Função e subrotinas, e Regra 6.44, Não implementes código em Módulos de Diálogo nem Blocos de Evento).

Portanto, se ainda usas ABAP clássico és um mariquinhas pé-de-salsa.

Obrigado a dawnhops pela foto.

O Abapinho saúda-vos.

18 comentários a “Se ainda não usas ABAP Objects és mariquinhas pé-de-salsa”

  1. Custodio Diz:

    No HELP do ABAP, ao pressionar sobre PERFORM ja diz:

    “Subroutines are obsolete. Do not create new subroutines in new programs. Subroutines created in existing programs for internal modularization can continue to be called. Avoid external calling subroutines from other programs as far as possible.”

    Mas acho (quase) impossivel parar tao cedo com o esquema
    START-OF-SELECTION.
    PERFORM READ_TABLES.
    PERFORM PROCESSA_DADOS.
    PERFORM EXIBE_RELATORIO.

  2. admin Diz:

    Custodio:

    REPORT Z123.
    
    DATA: go_z123 TYPE REF TO ZCL_Z123.
    
    PARAMETERS: p1 TYPE i.
    
    INITIALIZATION.
      CREATE OBJECT go_z123.
    
    START-OF-SELECTION.
      go_z123->main( i_p1 = p1 ).
    

    No método MAIN() chamas os métodos privados READ_TABLE(), PROCESSA_DADOS() e EXIBE_RELATORIO().
    E pronto, paraste com o esquema dos PERFORMs.

  3. Custodio Diz:

    Claro, Nuno.

    Mas eu digo a mudanca de atitude, nao a mudanca tecnica. E OO “de verdade” eh muito mais que isso, ne?

    Abraco

  4. admin Diz:

    Não podia estar mais de acordo.

  5. Bruno Filipa Diz:

    Boas,

    É verdade que os objetos chegaram há relativamente pouco tempo ao ABAP e há muita gente um bocado “histérica” com isso… Mas já a minha avó me dizia que tudo deve ser feito com “conta, peso e medida”. :)

    No exemplo dado as vantagens dos objetos em relação ao ABAP “clássico” (conceito novo para mim) são, do meu ponto de vista, absolutamente nulas!

    Tão importante como conhecer uma técnica acho que é reconhecer a altura indicada para a aplicar…

    Abc,
    Bruno

  6. admin Diz:

    Bruno,

    As vantagens não são nulas. Repara:

    1. Numa classe podes usar classes de excepção, que tem vantagens ENORMES no tratamento de erros.

    2. Os métodos podem ter um valor de retorno (RETURNING). Estes métodos podem ser usados directamente nos IFs:
    IF factura_bloqueada(x) IS NOT INITIAL.
    Ora se usares FORMS tens de declarar uma variável e não consegues fazer a coisa numa só linha:
    DATA: y TYPE FLAG.
    PERFORM factura_bloqueada USING x RETURNING y.
    IF y IS NOT INITIAL.

    3. Numa classe podes distinguir entre os métodos públicos (portanto acessíveis a partir de fora) e os privados. Enquanto que usando FORMs não. Outra pessoa que pegue num desenvolvimento sem o conhecer, terá mais facilidade em saber onde começa e como flui.

    4. A navegação na SE24, segmentada por módulos, é muito mais simples do que andar a fazer page up e page down em includes com mais de 1000 linhas

    5. A forma como as coisas ficam modularizadas numa classe potencia mais a reutilização de código do que uma série de FORMs a eito num include.

    Arranjam-se mais vantagens, mas para já estas 5 chegam. Ora agora diz-me lá tu 5 vantagens em não usar OO :)

    Abraço,
    Nuno

  7. Bruno Filipa Diz:

    Olá Nuno,

    A tua resposta limita-se a listar-me vantagens da utilização de ABAP OO de uma forma geral… Falta-lhe só uma coisa: contexto!

    Obviamente que o ABAP OO tem essas vantagens todas que listaste e mais ainda… Nenhuma delas me parece aplicável, com mais valia significativa, no exemplo dado.

    Acima de tudo aquilo com que não concordo é o “fanatismo” com que tu defendes que se use objetos para tudo e mais alguma coisa (até para o mais simples dos relatórios).

    Quando se está num cliente que te pede para fazer um relatório para “ontem”, em que tens que mostrar dados de meia dúzia de tabelas, porque é que eu hei-de mudar a minha abordagem “tradicional” quando a única coisa que ganho com isso é ter que andar a passear por mais uma transação (SE24), e perder tempo com isso?

    Comentando as vantagens que enumeraste…

    1/2 – Muito úteis sem dúvida… Relevantes e aplicáveis (classes de exceção..) num simples relatório para visualizar dados…?

    3 – Dizer que a existência de métodos públicos e privados faz com que “Outra pessoa que pegue num desenvolvimento sem o conhecer, terá mais facilidade em saber onde começa e como flui.” parece-me uma generalização sem fundamento óbvio. Uma pessoa com raciocínio mal estruturado vai fazer código mal estruturado usando FORMs, objetos, FMs, ou outra coisa qualquer, sendo o inverso também verdade.

    4 – Não sei como é que tu navegas nos teus includes, mas eu carrego no “Display Object List” na SE38 e faço duplo click em cima da rotina para onde quero ir. :)

    5 – A história da reutilização de código levava-nos a outra discussão interminável:)… Para mim tem vantagens e desvantagens e, tal como as classes, faz sentido em certos contextos enquanto que noutros só serve para complicar…

    Tinha mais umas coisitas para comentar contigo acerca deste assunto mas não quero que percas leitores por acharem estes testamentos uma seca. :D

    PS: Acho que tu sabes isto mas… esta minha opinião não é de ignorante em ABAP OO que recusa a mudança como um utilizador chato por não saber como se faz… Estudei programação OO fora de ABAP e também me sinto perfeitamente à vontade com (e uso quando acho pertinente) ABAP OO… Não sou é fundamentalista…nem a favor nem contra! :)

    Grande abraço,
    Bruno

  8. Sérgio Fraga Diz:

    Boas,

    depois de ler os vossos comentários, vou tentar contribui um pouco para o debate.

    Desde há um ano para cá que tenho tentado construir os meus desenvolvimentos com OO sempre que posso. Inicialmente o meu desejo era explorar os objectos em SAP uma vez que na maioria das linguagens com que trabalhei, esse era o paradigma usado, e honestamente, quando comecei a programar em ABAP, a “metodologia clássica” dos forms parecia-me de alguma forma desactualizada.

    Na minha opinião, escrever um relatório simples para a visualização de dados é tão moroso em “ABAP clássico” como em ABAP OO. Isto claro se a pessoa dominar os dois conceitos de igual forma. Consigo compreender que se num cliente que exige um relatório para ontem, não dominando OO com a confiança necessária, é mais simples e seguro avançar com a metodologia dos INCLUDES.

    Não estou com isto a dizer que o Bruno não domina OO, tenho a certeza que sim, mas a verdade é que já me deparei com alguns colegas que gostariam de avançar para OO, mas por limitações de prazos apertados, o mais seguro é de facto a outra via, o que se compreende perfeitamente.

    O que estou a tentar dizer é que para mim, o tempo de produção do relatório é essencialmente mesmo.

    Relativamente às vantagens de ABAP OO, uma que descobri recentemente, é que eliminas o chamado Funcional Wannabe Abaper.

    Não sei se já vos aconteceu em projecto… O funcional pede um relatório, tu estruturas a coisa e passas ao desenvolvimento. No dia seguinte chegas ao trabalho e ouves:

    “Epah estive só a dar uma vista de olhos no teu código e lembrei-me de mais umas coisas que faltavam por isso decidi alterar o programa.”

    Perplexo, olho para o código e está um caos…

    Ora com ABAP OO passa a ser:

    “Epah estive a dar uma vista de olhos no teu código e não percebi nada do que tens para lá! É preciso fazer umas melhorias, actualizei o documento de especificação (quando existe claro)”

    Se eu não ando a passear pela SPRO a meter piscos, o funcional não deve achar que sabe programar, mas isto já é outra discussão…

    É claro que esta “vantagem” é em tom de brincadeira mas é real, e que na realidade o Funcional nem chave de desenvolvimento deve ter, mas ele há os que a têm…

  9. admin Diz:

    Bruno,

    1/2: Tens razão, faltava-me contexto. E realmente num relatório simples do tipo OBTEM_DADOS + MOSTRA_ALV não há grande necessidade de usar classes de excepções. Nem sequer objectos :)

    Mas vamos deixar uma coisa clara: criar uma classe e fazer a coisa por métodos não demora nem mais um segundo do que usar FORMs. O Sérgio Fraga também o diz acima. E aí é que está: não há absolutamente razão nenhuma para não usar uma classe em vez de um include com FORMs.

    Se o programa for tão simples que não precise de mais do que um OBTEM_DADOS e um MOSTRA_ALV, tudo bem, também não vejo necessidade. Mas… da minha experiência, uma boa parte desses relatórios acabam por ter de fazer uma série de cálculos. Ora, quando são muitos, convém modularizá-los. E aí, um método é em tudo melhor que um FORM.

    3: Sim, é tão possível fazer merda com os OO como com os FORMS. Basta não saber pensar estruturadamente. Mas o certo é que os métodos permitem a quem sabe organizar a coisa melhor. Enquanto os FORMS… é tudo ao molho e fé em zeus.

    4. Realmente é raro usar o Display Object List para navegar entre FORMs. Tens razão, devia usar mais. Mas não o compares com a SE24 que permite ver parâmetros, excepções, etc. Mas ok, não é por aqui. Esqueçamos este argumento no caso dos relatórios simples.

    5. Pois, também concordo contigo que nem sempre é possível reutilizar. E no caso de um relatório ainda menos, por isso, concordo, este argumento também não é para aqui chamado.

    Mas repara: Isto não é uma opinião minha, tipo fanático solitário. A razão de ser deste artigo prende-se exactamente com mostrar ser a própria SAP a pedir encarecidamente para já ninguém criar mais FORMs e para toda a gente usar OO. Por alguma razão será. E não me parece que seja capricho. Aqui vem então o sexto argumento que na verdade devia ser o primeiro:

    6. Quando depois de amanhã a SAP introduzir novas funcionalidades que permitam criar relatórios de forma simples recorrendo apenas a classes (coisa que hoje não é possível) será muito mais simples migrar uma coisa que já está escrita em OO do que andar a converter código escrito em FORMs. Ou seja, usar FORMs hoje é escrever código obsoleto, que poderá vir a obrigar um esforço maior de reescrita por outro alguém no futuro.

    Como nota final: nos dias que correm, em que o relativismo está na moda, qualquer pessoa que defenda uma ideia com mais força vai logo parar ao saco dos fundamentalistas. Ok, assumo-me como fundamentalista do OO :) Mas olha que é à pala dos fanáticos que o fundamentalismo anda mal visto. Porque pode ser-se fundamentalista sem se ser fanático :)

  10. Gleisson BH Diz:

    Olá à todos!

    Nuno, você comprou este livro na SAP Press e foi entregue pra você aqui no Brasil ou teve algum intermediário na terra do tio Sam pra te enviá-lo? Sou juninho e estou interessado em comprá-lo.
    Abraços e parabéns pelo bom trabalho no blog!

  11. admin Diz:

    Olá Gleisson, eu sou português, moro em Lisboa. O livro veio por correio até Lisboa sem problema.
    Obrigado :)

  12. admin Diz:

    Bruno, acabei de criar um relatório muito simples, com 56 linhas. Correrá num job que actualiza uma tabela com base noutra. De tão simples, não criei classe nenhuma. Vês? Não sou fanático ;)

  13. Bruno Filipa Diz:

    Olá Nuno,

    Sim, está provado que não és fanático do ABAP OO. :D
    Retiro essa parte do que disse nos meus comentários anteriores. :)

  14. admin Diz:

    Ufa! Que alívio! :)

  15. Vítor Pinheiro Diz:

    Enquanto o OO estiver metido a martelo no SAP, trazendo apenas metade das supostas vantagem da metodologia. Não vou substituir a normal utilização dos reports com FM e forms.
    Então classes num desenvolvimento grande temos que ter muito cuidado ou cada vez que se tiver que fazer um debug temos um esgotamento….

  16. Nuno Godinho Diz:

    Vítor, estamos neste momento na fase de testes de um projecto de raiz com um prazo maluco e que, na minha opinião, só o conseguimos fazer dentro do prazo e de forma decente por termos usado OO. Neste momento tem cerca de 30 classes. Vai lá perguntar ao Sérgio Fraga, ao Miguel Jorge e ao José Faria se eles acham que em algum dia se teria conseguirdo fazer a mesma coisa sem OO. E já agora pergunta-lhes se com FM e forms não estavam já com um esgotamento ou com vontade de dar um tiro no polegar.

  17. Ricardo Diz:

    Não concordo nem discordo muito pelo contrario.

  18. Esperança Diz:

    Boas!

    Agora que vejo o comentário do Vítor realmente lembrei-me… sempre que estou a chafurdar no standard e me aparecem objectos à frente quase que dou um tiro na cabeça… isso porque me é extremamente difícil perceber e navegar pelos atributos dos objectos e tentar perceber os valores que lá estão guardados e onde. Se alguém tiver uma dica para me dar neste âmbito será extremamente bem-vinda.

    Obrigado! Cumps!!

Deixe um comentário


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