OO编程优于过程编程的五个原因
下面的部分里我们将着重论述OO编程的主要优点，尽管这里所提到的优点与其他的OO语言（JAVA C++）没有什么太大的区别,我们这里着重在ABAP OO与传统的ABAP程序相比而体现处来的优点。我们将通过实现一个银行账户管理的简单例子来比较两种模式的差别。
原因一：数据封装
将数据和程序封装在一个组件中将使程序变得容易修改。不要把一个应用的所有的数据和功能放在同各超长的程序里，你只需要把你的应用通过组件的稳定的接口把需要的部分包进来即可。如果一个封装的组件有一个好的接口，而这些接口的设计比较完善的话，那么这些接口的内部结构就会被很好的隐蔽起来，对这个部件的内部的修改便不会影响到应用的其他部件。让我们来看看面向过程和面向对象的方式是如何实现封装的。
面向过程模式的封装
在面向过程模式中有两种变量：
全局变量：他在程序的全部分声明，可以在程序的仍何不分应用。
局部变量：他在某个过程（form of function module）中声明也只能在其中应用。
全局变量的生命周期取决于整个程序的生命周期，局部变量的生命周期取决于该过程的生命周期。由于生命周期的限制，局部变量不适合于封装，它是过程中为了达到某个目的而使用的辅助变量。如果没有使用TABLES和COMMON PARTS语句那么程序中所声明的全局变量只能被该程序内部的各个模块调用。那么这就决定了在面向过程的模式中数据的封装只对程序本省有效。下面是一个简单的如何通过功能池实现对一个银行帐号的封装。
Function-pool Account
DATA: current_account TYPE accounts-amount.
Function deposit.
* IMPORTING REFERENCE(amount) TYPE account-amount
Current_amount = current_amount + amount.
EndFunction.
Function withdraw.
* IMPORTING REFERENCE(amount) TYPE account-amount
* RAISING
* CK_NEGATIVE_AMOUNT
IF current_amount > amount.
Current_amount = current_amount – amount.
ELSE.
RAISE EXCEPTION TYPE CK_NEGATIVE_AMOUNT.
ENDIF.
ENDFUNCTION.
这个模块池封装了银行账户的余额，并且通过功能模块deposit和withdraw来处理银行账户的余额。虽然单单是一个银行帐号的话这个模块池工作的非常好，但如果是多个应行帐号并要实现银行帐号之间交互的功能，问题就出现了。为了实现现实世界中多个银行帐号的管理，你不得不为每一个银行帐号建一个唯一名字的模块池和功能模块，这显然是不可取的。下面是个把所有银行帐号封装在一个模块池中的例子：
FUNCTION-POOL accounts.
DATA: account_table TYPE SORTED TABLE OF accounts
WITH UNIQUE KEY id.
ENDFUNCTION.
LOAD-OF-PROGRAM.
SELECT * INTO TABLE account_table
FROM accounts.
FUNCTION deposit.
* IMPORTING
* REFERENCE(id) TYPE accounts-id
* REFERENCE(amount) TYPE accounts-amount
DATA: account_wa TYPE accounts.
READ TABLE account_tabe
INTO account_wa
WITH TABLE KEY id = id.
Account_wa-amount = account_wa-amount + amount.
MODIFY account_table FROM account_wa.
ENDFUNCTION.
FUNCTION withdraw.
* IMPORTING
* REFERENCE(id) TYPE accounts-id
* REFERENCE(amount) TYPE accounts-amount
* RAISE
* CX_NEGATIVE_AMOUNT
DATA: account_wa TYPE accounts.
READ TABLE account_table
INTO account_wa
WITH TABLE KEY id = id.
IF account-amount > amount.
Account-amount = account-amount – amount.
MODIFY account_table FROM account_wa.
ELSE.
RAISE EXCEPTION TYPE CX_NEGATIVE_AMOUNT.
ENDIF.
ENDFUNCTION.
FUNCTION transfer.
* IMPORTING
* REFERENCE(id_from) TYPE accounts-id
* REFERENCE(id_to) TYPE accounts-id
* REFERENCE(amount) TYPE accounts-amount
* RAISE
* CX_NEGATIVE_AMOUNT
CALL FUNCTION ‘withdraw’
EXPORTING id = id
Amount = amount.
CALL FUNCTION ‘deposit’
EXPORTING id = id
Amount = amount.
ENDFUNCTION.
这样多个银行帐号就被封装在内表account_tab中，每个银行帐号是通过关键字ID来区分的。内表account_tab在模块池被调用时被填充以便模块池中的所有功能模块都可以使用它。功能模块deposit和withdraw通过id来处理一个银行帐号，而新的功能模块transer来实现两个银行帐号之间的转账。这样我们通过一定的技巧实现了多个银行帐号的管理但是为了区别每个银行帐号却增加了每个功能模块接口参数的复杂性。
转载于:https://www.cnblogs.com/andyfurong/archive/2011/01/05/1926407.html
来源：CSDN
作者：weixin_30500289
链接：https://blog.csdn.net/weixin_30500289/article/details/97187930