Transaction、Rollback、Commit試験 [プログラム研究室]

　こんにちは！
　ナビゲータのEVEです。
　本日から、Transaction、Rollback、Commitに関する試験をしていますが、その試験に付随して、継承について疑問がたくさん出てきました。
　問題を整理し、今後どうしたらいいのか検討していきたいと思います。

[Transaction、Rollback、Commitでの問題点]

　EVEシステムで利用しているTransaction、Rollback、Commitは、EVEシステムのフレームワーク側で、フラグ制御し処理しようとしています。しかし、New Prototype EVEは、アプリケーション群側で行っているため、アプリケーションから、Transaction、Rollback、Commit処理を実行しています。
　New Prototype EVEでは、オーバーライドで作成したTransaction、Rollback、Commitは、普通に利用できます。ただ、フラグ制御していないNew Prototype EVEへ、確定予約フラグを設定すると、Rollbackしようとしても、Rollbackできません。ようは、Rollbackする前に、オーバーライド前の、EVEシステムフレーム側のCommit処理が動作するのです・・・？？？よく分かりません・・・。インポートしているのは、New Prototype EVEなのに・・・？New Prototype EVEでは、フラグ制御していない、Transaction、Rollback、Commitが定義されているだけなのに・・・？

[以上の結果を受けて]
　以上の結果を受けて、すべてのプロパティをカプセル化することにしました(一部はあきらめました)。そこでまた問題が・・・？
　オーバーライドしているメソッドでは、親クラスのprivateプロパティは見ることができるのですが、オーバーライドしていない子クラスのメソッドでは、privateプロパティは見ることができません。
　また、子クラスから親クラスのメソッドを呼び出して親クラスのプロパティへ設定した値を参照できますが、子クラスから、親クラスのプロパティへ、直接設定した値は、見ることができませんし、エラーにもなりません。
　仕方がないので、値を取得する項目については、子クラスから直接親クラスのプロパティを覗くのではなく、setterやgetterを用意して見ることにしました。getterだけでは、無理そうです・・・？違いますか？？？

[どんな機能があるか分からない]
　以上のような経験を踏まえて、作らないといっていた、setterやgetterを用意することにしたのですが、作ってメリットがあることが分かりました。
　メソッドを作ったことにより、クラスにどんな機能があるのか明確になるのです。
　昨日、今日クラス継承するプログラムを作ってみて分かったことは、
1)当該クラスを利用しようとした場合、当該クラスの「親クラス＋子クラス」の全ての機能を利用できる
2)メソッド、プロパティ名が同じものについては、オーバーライドされ、子クラスのものが優先されます。
　当然、親クラスから、子クラスまで全てのプログラムソースを見れば分かるのですが、面倒です。ただ、メソッドを定義しておけば、クラスとしての機能が一目で分かります。ただ、オーバーライドされているかどうかは、親と子両方見なければ分かりませんが・・・。
　という状況で、もうちょっと、継承について調べてみます。それが終わってから、New Prototype EVEの全面改修工事にかかります。
　では、また！！！