Ruleは四種類あり、その一つEntry仕掛けの構造。
ここの見通しはあまり良くない。
ソースコード./lib/rule/entry/entry.rbを見て分かることは。
エントリ時にチェックする仕組みを用意している。
最終的には、
check_long,check_shortというメソが呼び出されているが、
これは更に具体的な子クラスの方で実装されるらしい。
どうやら、
外からEntryのメソッドcheck_long_entry,check_short_entryを呼び出す。
データがnilの時は処理を飛ばしながら、仕掛けたら、Tradeクラスを生成して返す。
ようになっている。
このとき内部では、
実装されたcheck_long,check_shortが呼ばれ、
仕掛けるべきかどうかの判断を下し、
仕掛けるべし、なら、そこでenter_long,enter_shortを呼び出し、
仕掛けを実行したTradeクラスが生成される。
という流れである。
分かるけど、あんまり設計としては綺麗じゃないな。
check_long,check_shortでは仕掛けるべきかどうかの判断だけして、
親のメソッドは呼び出すべきじゃない。
コードで書くと例えば、
def check_long_entry(index)
with_valid_indicators {check_long(index)}
end
のところは、
with_valid_indicators {
param = check_long(index)
if param
enter_long(index, param)
end
}
のように、
まあ、ちょっとかっこよくはないが、そこは如何様にも工夫できるだろう。
構造は親の方から仕組みが見えていて、
詳細な処理は子供の方に任すというように作らないと、
見通しが効かない。
親が子供のメソッドを呼んで、
さらに子供が親のメソッドを呼ぶという入れ子構造はやっちゃダメ。
処理の流れは必ず一方通行にしておかないと。
親→子、外から内にというイメージで。
オブジェクト指向のポリモリフィズムとか、
具体的に違うところだけ書き直すというのは、そういうことなんだけど、
補処的な関数を親の方で用意しておくわけじゃなく、
処理の本筋が入れ子構造になってる。
これは良くない。可能な限り避けたい。継承関係では避けたい。
恐らく、見通しが効くように最初に設計してから実装したのでなく、
どんどん進んでから、この構造に到達したのだろう、
が、まあ構造はわかったので、
文句を言っても始まらない。好ましくないとだけ言っておいて、
次はExitに移る。
質問コーナー、お問い合わせは、sanpome.net@gmail.com まで。
