Los patrones de comportamiento se concentran en la interacción mostrando cómo los objetos intercambian información, distribuyen tareas y ejecutan una lógica sofisticada como parte de una operación unificada.
Los elementos dinámicos del sistema reciben atención de los patrones de comportamiento, los patrones de creación manejan la creación de objetos y los patrones estructurales manejan la disposición de los objetos. Estos patrones le ayudan a estructurar algoritmos y distribuir el trabajo y la gestión del estado, lo que da como resultado programas flexibles y fáciles de mantener que puede ampliar fácilmente.
Tipos de patrones de comportamiento
Algunos patrones de comportamiento comunes que puede encontrar al desarrollarse con ABAP incluir lo siguiente.
Cadena de Responsabilidad
El patrón de cadena de responsabilidad pasa una solicitud a lo largo de una cadena de controladores hasta que uno de ellos la procesa. En ABAP, esto podría aplicarse a la lógica de validación con múltiples clases de condiciones de verificación (como autorizaciones, integridad de datos y reglas comerciales) hasta que un controlador maneja la solicitud o la falla.
Dominio
El patrón de comando encapsula una solicitud como un objeto, lo que le permite parametrizar clientes y poner en cola, registrar o deshacer acciones. En ABAP, esto es útil para tareas de flujo de trabajo o trabajos en segundo plano, donde cada objeto de comando representa una unidad de trabajo que se puede ejecutar o revertir.
Intérprete
El patrón de intérprete define la gramática e interpreta oraciones en esa gramática. Si bien no es tan común en el ABAP cotidiano, se puede utilizar para analizar reglas comerciales simples, fórmulas o lenguajes de consulta de dominios específicos almacenados en tablas de Customizing.
Iterador
El patrón iterador proporciona una forma de acceder a elementos de una colección de forma secuencial sin exponer la representación subyacente. En ABAP, las clases de iteradores personalizados pueden recorrer tablas internas, resultados de selección o incluso conjuntos de retorno BAPI, brindando a los consumidores una interfaz limpia para consumir datos fila por fila.
Mediador
El patrón mediador centraliza la comunicación compleja entre objetos, asegurando que no necesiten hacer referencia entre sí directamente. Las aplicaciones ABAP que coordinan múltiples controles de UI o servicios modulares pueden beneficiarse de un mediador que enrute mensajes a través de un único centro.
Recuerdo
El patrón de recuerdo captura y restaura el estado interno de un objeto sin exponer sus partes internas. En ABAP, esto puede resultar útil cuando implementa la funcionalidad de deshacer para transacciones de usuario o cuando guarda y restaura el estado de un objeto complejo durante el procesamiento por lotes.
Observador
El patrón de observador define una dependencia de uno a muchos, de modo que cuando un objeto cambia de estado, se notifica a todos los dependientes. ABAP admite este patrón de forma natural a través de eventos de clase y controladores de eventos, lo que lo convierte en una opción para escenarios en los que varios consumidores reaccionan ante una única fuente de verdad.
Estado
El patrón de estado permite que un objeto altere su comportamiento cuando cambia su estado interno. En ABAP, puede modelar el ciclo de vida de un pedido de ventas (es decir, creado, liberado, bloqueado y facturado) como un conjunto de objetos de estado, cada uno de los cuales controla qué acciones son posibles.
Estrategia
El patrón de estrategia define una familia de algoritmos y le permite intercambiarlos en tiempo de ejecución. Esta es una opción natural en ABAP cuando desea elegir entre múltiples estrategias de cálculo, impuestos o precios, según la personalización o el contexto.
Método de plantilla
El patrón del método de plantilla define el esqueleto de un algoritmo en una clase base, lo que permite a las subclases redefinir ciertos pasos. Los marcos de SAP utilizan esto ampliamente y los desarrolladores de ABAP pueden aplicarlo en escenarios como el procesamiento de facturas, donde el proceso general es fijo pero los pasos específicos varían según el tipo de documento.
Visitante
El patrón de visitante le permite definir nuevas operaciones en una estructura de objeto sin cambiar los objetos mismos. Aunque es menos común en ABAP, puede ser útil en estructuras jerárquicas (como listas de materiales o organigramas), donde desea aplicar diferentes operaciones (como validación, informes y transformación) sin saturar los objetos con todos los comportamientos posibles.
Explicaremos cómo puede utilizar patrones de comportamiento con más detalle en las siguientes secciones, incluido un análisis más detallado del patrón de estrategia.
Cuándo utilizar patrones de comportamiento en ABAP
Los patrones de comportamiento ayudan a los desarrolladores a separar los aspectos funcionales de su código de los detalles de implementación. Le permiten crear bloques de comportamiento reutilizables que permiten la delegación de solicitudes entre múltiples controladores, la transmisión de eventos a suscriptores y el reemplazo de algoritmos. Estos patrones coinciden con las características naturales del lenguaje ABAP a través de su implementación de eventos de clase, manejo de excepciones y programación basada en interfaces.
Los sistemas ABAP que operan durante décadas con una lógica empresarial compleja se benefician de los patrones de comportamiento porque estos patrones transforman complicados enredos de declaraciones IF en diseños adaptables. Los marcos de SAP implementan varios patrones a través de motores de flujo de trabajo (comando y cadena de responsabilidad), manejo de eventos de UI (observador y mediador) y marcos de aplicaciones que proporcionan plantillas de procesos comerciales (método de plantilla). Reconocer estos patrones le ayudará a mejorar sus habilidades ABAP y podrá comprender y analizar mejor el código SAP estándar.
Patrón de estrategia
El patrón de estrategia permite a los clientes seleccionar algoritmos de una familia de interfaces común en tiempo de ejecución. Se evitan ramas IF… ELSEIF… distribuidas para la selección de cálculo en el sistema al mover esta decisión a la fase de construcción o configuración, y el resto del sistema puede usar la interfaz. La selección de reglas de impuestos, precios y/o redondeo coincide perfectamente con la Personalización porque los usuarios realizan selecciones basadas en la sociedad, el país, el tipo de documento o la alternancia de funciones. El patrón estratégico mantiene opciones explícitas que siguen siendo comprobables y reemplazables.
El cálculo de los impuestos sobre los artículos de venta requiere una atención cuidadosa. Los requisitos difieren entre países y, a veces, entre grupos de productos. El sistema requiere que cada algoritmo funcione de forma independiente, pero la persona que llama debe interactuar con la estrategia impositiva sin saber qué algoritmo se ejecuta porque la persona que llama solo necesita solicitar el cálculo de impuestos para un artículo específico.
Veamos un patrón de estrategia de ejemplo. Primero, definirá la interfaz de la estrategia: un pequeño contrato que revela la intención.
INTERFACE zif_tax_strategy PUBLIC.
METHODS compute_tax
IMPORTING is_itemTYPE zty_so_item " your domain type
RETURNING VALUE(rv_tax) TYPE decfloat34
RAISING cx_static_check.
ENDINTERFACE.
A continuación, proporcione algunas estrategias concretas, como se muestra en la lista siguiente. Mantenga cada una centrada en su conjunto de reglas. Por ejemplo, creamos una estrategia fiscal estadounidense que solo tiene lógica relacionada con los impuestos establecidos en Estados Unidos. También creamos una clase para una estrategia fiscal de la UE que solo tiene lógica relacionada con las estrategias fiscales europeas.
CLASS zcl_tax_strategy_us DEFINITION PUBLIC CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES zif_tax_strategy.
ENDCLASS.
CLASS zcl_tax_strategy_us IMPLEMENTATION.
METHOD zif_tax_strategy~compute_tax.
" Simplified: destination-based, flat rate example
rv_tax = is_item-net_amount * CONV decfloat34( '0.060' ).
ENDMETHOD.
ENDCLASS.
CLASS zcl_tax_strategy_eu DEFINITION PUBLIC CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES zif_tax_strategy.
ENDCLASS.
CLASS zcl_tax_strategy_eu IMPLEMENTATION.
METHOD zif_tax_strategy~compute_tax.
" Simplified: VAT based on material group
DATA(lv_rate) = COND decfloat34(
WHEN is_item-matkl="FOOD" THEN '0.04'
WHEN is_item-matkl="BOOK" THEN '0.07'
ELSE '0.20' ).
rv_tax = is_item-net_amount * lv_rate.
ENDMETHOD.
ENDCLASS.
un pequeño contexto El objeto utiliza el patrón de estrategia. No sabe (ni le importa) qué estrategia adoptó. Nuestro ejemplo a continuación muestra la implementación de una calculadora de impuestos. El propósito de la clase es simplemente calcular los impuestos de un artículo. No debería tener que saber para qué país está calculando impuestos o los diferentes tipos de estrategias que existen para calcular impuestos. Sólo necesita saber que tiene un artículo y necesita calcular el impuesto; ese debería ser su único propósito.
CLASS zcl_tax_calculator DEFINITION PUBLIC CREATE PUBLIC.
PUBLIC SECTION.
METHODS constructor IMPORTING io_strategy TYPE REF TO zif_tax_strategy.
METHODS tax_for_item
IMPORTING is_item TYPE zty_so_item
RETURNING VALUE(rv_tax) TYPE decfloat34
RAISING cx_static_check.
PRIVATE SECTION.
DATA mo_strategy TYPE REF TO zif_tax_strategy.
ENDCLASS.
CLASS zcl_tax_calculator IMPLEMENTATION.
METHOD constructor.
mo_strategy = io_strategy.
ENDMETHOD.
METHOD tax_for_item.
rv_tax = mo_strategy->compute_tax( is_item = is_item ).
ENDMETHOD.
ENDCLASS.
Finalmente, conéctelo. Una estrategia se puede determinar mediante el Customizing, indicadores de características o una clase de fábrica. Nuestro ejemplo a continuación muestra la estrategia determinada por una clase de fábrica, donde pasamos el código de país y eso determina qué estrategia fiscal se crea una instancia para usarse dentro de la calculadora de impuestos.
CLASS zcl_tax_strategy_factory DEFINITION PUBLIC CREATE PUBLIC.
PUBLIC SECTION.
CLASS-METHODS for_context
IMPORTING iv_country TYPE land1
RETURNING VALUE(ro_strategy) TYPE REF TO zif_tax_strategy.
ENDCLASS.
CLASS zcl_tax_strategy_factory IMPLEMENTATION.
METHOD for_context.
CASE iv_country.
WHEN 'US'. ro_strategy = NEW zcl_tax_strategy_us( ).
WHEN 'DE'
OR 'FR'
OR 'ES'. ro_strategy = NEW zcl_tax_strategy_eu( ).
WHEN OTHERS.
RAISE EXCEPTION TYPE cx_static_check
EXPORTING textid = cx_static_check=>default_textid. "handle gracefully
ENDCASE.
ENDMETHOD.
ENDCLASS.
A continuación se muestra el uso de esta estrategia con la calculadora de impuestos.
DATA(lo_strategy) = zcl_tax_strategy_factory=>for_context( iv_country = 'US').
DATA(lo_calculator) = NEW zcl_tax_calculator( lo_strategy ).
DATA(lv_tax) = lo_calculator->tax_for_item( is_item = ls_item ).
La solución sigue siendo mantenible porque cada nueva introducción de reglas permite a los desarrolladores crear nuevas clases que amplían la clase de fábrica sin afectar las estrategias existentes. Las pruebas unitarias ABAP pueden crear estrategias falsas para la simulación de escenarios, mientras que usted puede probar cada regla de estrategia de forma independiente. El código de dominio se vuelve más legible al incluir un método sencillo llamado Compute_tax en lugar de implementar varias ramas de países y tipos de productos.
Tenga en cuenta lo siguiente cuando utilice patrones de estrategia:
- La interfaz no debería expandirse demasiado. La interfaz del sistema debe mantener un diseño compacto y solo debe tener uno o más métodos relacionados que utilicen los mismos tipos de dominio. Para abordar diferentes necesidades de entrada, las estrategias reciben una estructura de contexto opcional (zty_tax_context). Siempre debe documentar su uso específico en el campo.
- Evite el uso de información de configuración dentro de las estrategias en la lógica principal. La recuperación de la configuración debe ocurrir una vez con un constructor o un pequeño objeto de configuración, mientras que la lógica debe ser pura y libre de efectos secundarios. Esto mantiene sencillo el proceso de pruebas unitarias.
- Utilice referencias de interfaz como enfoque estándar en todos los contextos de programación. La interfaz zif_tax_strategy debería ser el único punto de referencia para las personas que llaman, en lugar de clases concretas.
- Puede minimizar el impacto en el rendimiento al seleccionar estrategias almacenando en caché la instancia seleccionada en cada contexto o manteniendo un pequeño registro.
Conclusión
El patrón de estrategia existe en todas las aplicaciones ABAP, incluidos cálculos de impuestos, lógica de precios, funciones de redondeo, asignación de números, conversión de moneda, cálculo de descuentos y serialización a través de métodos de codificación de interfaz compartida. Cualquier situación que requiera una declaración CASE para seleccionar un algoritmo debe implementar el patrón de estrategia.
Los patrones de comportamiento establecen reglas de interacción estandarizadas entre objetos. Estos patrones definen cómo los objetos se comunican y trabajan juntos, mientras que los patrones de creación determinan los métodos de creación de objetos y los patrones estructurales determinan los métodos de ensamblaje de objetos. Los desarrolladores ABAP pueden utilizar estos patrones para crear algoritmos aislados y responsabilidades delegadas y cambios en las condiciones de tiempo de ejecución. El patrón de estrategia proporciona una implementación exitosa que permite el cambio de lógica en tiempo de ejecución sin requerir modificaciones en el código de llamada existente. El patrón de observador, junto con el método de plantilla y el patrón de comando, comparten principios de diseño similares porque proporcionan soluciones extensibles para gestionar la lógica compleja de una manera limpia.
¡Aprenda ABAP con los cursos de Rheinwerk!
¿Listo para mejorar tus habilidades ABAP? Explore la gama completa de nuestros cursos en línea centrados en ABAP, desde programación básica hasta RAP avanzado, CDS, AMDP, pruebas unitarias y más. Cada uno está dirigido por un instructor (en vivo y bajo demanda), incluye grabaciones y presentaciones de diapositivas, y está diseñado para brindarle habilidades prácticas que puede aplicar de inmediato en su panorama de SAP. ¡Haga clic en el banner a continuación para comenzar!
Nota del editor: esta publicación ha sido adaptada de secciones de los libros. Programación orientada a objetos con objetos ABAP por Jeffrey Boggess, Colby Hemond, James Maderay José Ruperto. jeffrey es un especialista en integración empresarial en Bowdark Consulting enfocado en crear integraciones perfectas entre SAP, Azure y Dataverse para resolver desafíos comerciales complejos y brindar soluciones confiables para los clientes. colby es consultor técnico senior en Bowdark Consulting, donde se dedica a brindar ideas y soluciones innovadoras a los clientes y apoyarlos en su transformación digital. Jaime es el fundador y director ejecutivo de Bowdark Consulting, Inc., una firma de consultoría especializada en tecnología y desarrollo personalizado en el panorama de SAP. José es arquitecto de datos senior en Bowdark Consulting, Inc. con experiencia en la migración de entornos SAP complejos a plataformas en la nube, lo que permite ecosistemas de datos escalables, seguros y de alto rendimiento.
Esta publicación se publicó originalmente el 6/2026.
