很早就想尝试着在常规的报表开发中
引入OO了
趁着程序略复杂 时间略充裕 终于尝试了一把…咩哈哈~~
以下来自我的evernote笔记 有点语无伦次…忍忍~~
---------------------------------------------------------------------------
主要的好处就是逻辑清晰
可以从整体上来直接把控这个程序
如果可以 减少对全局数据的依赖
保证class的独立性 说不定哪天可以复用一些方法
使用OO的话
刚开始可以专注于处理的实际业务特点
可以抽象出处理的业务模型
理解大致的业务逻辑
然后设计程序的架构
例如定义一个物料处理的接口
常用料 代管料分别实现该接口
这样逻辑清晰
而且在初期的编码阶段
无须关注具体实现过程
甚至无须关注有哪些变量
根据主要的业务逻辑
确定相关方法就OK
第一次尝试这样开发
在定义class的时候已经从整体上把握了整个程序
和以前的面向过程的
一路走下去 车到山前找条路的方式还是有进步的
而且对于用户需求变更 程序扩展 后期维护都方便
复杂的程序的开发难度降低不少(个人认为)
确定方法之后
再确定涉及的变量
在实际编码过程中再添加涉及的其他交互的方法
唯一个不爽的就是class中不能使用内表自带的Header line
每次都要用自己定义的工作空间
这个不是问题 只是自己没有定义额外的工作空间的习惯而已
还有潜在的一个问题是
class在内存中应该是放在inner session中的
所以在跳到另一个inner session时当前的class数据是无法使用的
而且不能通过放入abap memory的方式实现交互
但是这个问题对我的开发影响不大...
总结下 虽然很想整个报表全部都封装在class里
但是后来发现没有必要
面向过程在处理纯粹的逻辑跳转 数据筛选等等的操作还是挺有优势的
没有必要画蛇添足了
把OO的处理放在核心业务数据提取 处理上会更好
然后筛选的数据二次处理放在正常的代码块中
这样混合着使用的效率可能更高
代码就不贴了,没有借鉴的意义 需要配合着其他数据一起使用
就把简单的几个class放出来吧 纪念我第一使用abap 的OO
