将经典的屏幕逻辑从OO
的应用程序中分离出来
正如你所看到的,在大部分程序中屏幕逻辑和应用逻辑是紧密地联系在一起的。这些程序都是用户通过在屏幕中输入数据来驱动的,应用逻辑都写在modue或event block中。而对于ABAP OO来说,它主要是用来写应用逻辑而非屏幕逻辑。面向对象的ABAP OO不支持屏幕编程。
如果你想用OO的模式编写ABAP程序,你可能面临的问题便是如何把屏幕程序与之结合起来。
答案便是把应用逻辑从程序界面中分离出来。下面的一个简单的例子讲给你演示如何做到这一点。
下面的代码演示了如何通过模块池把应用程序需要的屏幕封装在一起。
FUNCTION-POOL flight_screens.
SELECTION-SCREEN BEGIN OF SCREEN 100 AS WINDOW.
PARAMETERS: p_carrid TYPE sflight-carrid,
P_connid TYPE sflight-connid,
P_fldate TYPE sflight-fldate.
SELECTION-SCREEN END OF SCREEN 100.
TABLES sflight.
FUNCTION get_flight_parameters.
CALL SELECTION-SCREEN 100 STARTING AT 10 10.
Carrid = p_carrid.
Connid = p_connid.
Fldate = p_fldate.
ENDFUNCTION.
FUNCTION get_plane_type.
Sflight-planetype = plane_type.
CALL SCREEN 200 STARTING AT 10 10.
Plane_type = sflight-planetype.
ENDFUNCTION.
在这个例子中包括一个selection screen100和一个screen 200。模块池和一般屏幕之间的接口通过TABLES语句来声明。功能模块来处理屏幕并通过参数来输入输出数据。
如果模块池中需要内部模块,可以通过本地类来实现。如果模块池屏幕中包含GUI控件,相应的事件处理也应当在模块池的本地类中实现。在这个简单的例子中并没有screen module。
如果你想使用输入检查这样的自动机制,那么你就要使用这些screen module了。不过要记住在这些module中要输入尽量少的代码而要尽量去调用本地类的方法。另外考虑到数据的封装性,应尽量减少直接操作全局变量。
下面的一段代码演示了如何在类flights中使用功能模块get_plane_type的屏幕。
CLASS flights DEFINITION.
PUBLIC SECTION.
METHOS: constructor,
Change_plane_type.
PRIVATE SECTION.
DATA flight TYPE sflight.
ENDCLASS.
CLASS flights IMPLEMENTATION.
METHOD constructor.
DATA: carrid TYPE sflight-carrid,
Connid TYPE sflight-connid,
Fldate TYPE sflight-fldate.
CALL FUNCTION ‘GET_FLIGHT_PARAMETERS’
IMPORTING
Carrid = carrid
Connid = connid
Fldate = fldate.
SELECT SINGLE * FROM sflight
INTO flight
WHERE carrid = carrid AND
Connid = connid AND
Fldate = fldate.
ENDMETHOD.
METHOD change_plane_type.
CALL FUNCTION ‘GET_PLANE_TYPE’
CHANGING plane_type = flight-planetype.
ENDMETHOD.
ENDCLASS.
这个类中的每个对象代表着表sflight中的一个flight。创建对象时,类的结构方法便会调用功能模块来取得选择屏幕上的业务主键。方法change_plane_type来处理屏幕200要求输入plane type,但是在类中没有任何屏幕逻辑。
只在应用程序中使用ABAP OO并将其与屏幕逻辑分离开来将为未来表现层技术的变革打下基础(比如SAP GUI和BSP)。屏幕逻辑和应用逻辑不再混合在一起,新的表现层的技术变革将限制一些过程的调用。不过有趣的是这种分离在面向过程的程序开发中也可以是实现只不过并没有强制。简单例证便是屏幕并不允许被作为类的组件。所以现在就应当尽量熟悉这种方式。