今回、先輩がやるという実験のために、インターフェース開発を私が、コアとなるモジュールを先輩が作ることになりました。簡単に言えば、文字列を受け取った先輩のモジュールが、結果として文字列を返すので、それを表示したりデータベースに書き込んだりするという流れになります。
私はMFCやらODBCやらで悩まされるわけです、といいましても、ODBC周りは以前一回悩んでいるのでさほど悩まずコーディングが完了します。悩ましいのは、クラスを追加したときなどVisual Studioが自動で生成してくれるヘッダの汚さですね…なんでprivateとpublicなメソッドを整理して並べないんでしょう。気持ち悪いです。
さて、開発を分担して行うということで、私の中では先輩のモジュールをスタティックリンクライブラリとして受け取り、適当に呼び出して完了だと思っていました。先輩はというと、ソースごと私に渡して、まとめてコンパイルさせるつもりだったようです。
スタティックリンクライブラリですよね?と聞くと、お顔にはてなマークが浮かんでいらっしゃったので、何もいわずにソースコードを受け取ることにしました。まぁ、こちらでライブラリ化してしまえば整理できる問題なので。気にせずライブラリ化に勤しみます。
ライブラリ化するにも、とにかく私が呼び出すべきメソッドはどんな名前で、どんなインターフェースなのかを調べる必要があります。メソッド名だけはメールで教えてもらっていたので、ああこれか、と分かりましたが、出力される文字列の形式がさっぱりです。あとは、サンプルプログラムをみてねみたいなノリだったので、少し頭を抱えることになりましたが…動かしてみて、出力データを見れば済むのでよしとします。
…どこに何が出力されるんだろう…という事態に陥ります。ともかく、ソースコードを追えば済む話です。…ってファイルに出力して結果の文字列を捨てちゃってるじゃないですか。じゃあ私のモジュール側でそのファイルを解析しにいけと?な、なんて周りくどいんだぁぁ…
これは文字列で渡すようにしてください、とメールを打っておきました。文字列を投げてくれれば良いところを、一度ディスクのIOを挟むのは無駄すぎです。
そしてライブラリ化をすすめるわけですが…まぁ、VSで作ったから仕方ないのかも知れませんが、メインとなるクラスのprivateメソッドや、使わない(私側には関係のない)publicメソッド、構造体定義が多すぎです。クラスの使い方が分かりづらくなるだけでなく、これらの(私にとって不要な)メソッドや型定義に必要なヘッダファイルのインクルードが大量に発生します。コンパイル時間が延びるだけです。
先輩のソースを改変してもいいのですが、後々先輩がソースコードを更新することを考えると下手にいじれません。ということで、先輩のモジュールをラップしたクラスを作ることにしました。このクラスでは必要最低限のメソッドしか定義していません。私にとって不要な定義は隠蔽したことになります。
隠蔽にはPimplイディオムを使います。ラッパークラスを作るにしても、継承を行えば先輩のモジュールのヘッダをインクルードしなければなりません。このヘッダは冗長な定義やインクルードによって、ヘッダファイル自体も巨大であり、冗長インクルードによるコンパイル時間の増幅を招きます。ですので、私のモジュール側では先輩のヘッダはインクルードしないほうがよいです。Pimplイディオムなら、先輩が定義したクラスらを完全に隠蔽できます。クラスを隠蔽してしまえば、利用者側である私のモジュールは先輩のクラスのインターフェースを知らなくてもいいわけですから、先輩のヘッダをインクルードしなくてもよくなります。
先輩のヘッダをインクルードしたくない理由はもう一つあります。グローバルなスコープで'using namespace std'を宣言してしまっていることです。ソースファイル内だけならともかく、外部公開用のヘッダに宣言してしまっているのです。ヤバイです。利用者は、宣言しているつもりが無くても、知らず知らずのうちに、stdという名前空間を省略して、stdに属するクラスらを利用できる状況に置かれてしまうわけですから。
ドクターの先輩なので、もっとハイレベルなコーディングができれば、もっと効率的に実験が進みますよ…なんて面と向かっては言えませんが、そんなことを思った一日でした。
No comments:
Post a Comment