デバッグ情報を得るためにパケットを送る部分を、既存のメソッドの再利用で実現しているんだけど、それを、そのメソッドをコピーして、ちょっと名前を変えて、中を少しだけ変えると言うわけ。それほど、多くはないが4-5メソッド位はあるらしい。
おかげで、メソッド同士の間違い探しを散々やるはめに... (自分の眼が、それに特化しているのがわかるのが悲しい... 学生のコピペ課題を見すぎたか...)
そういうことしたくないから、わざわざCの実装からJavaの実装に切替えたんだけどなぁ。かなり、いろいろ指導したつもりだけど、結局、土壇場になると地が出ちゃうという感じですかね。
あ、でも、Eclipse で同じソースを二つのWindowで同時に表示する方法を見つけました。C-X 2 にbindしたいよ... (と、役にたったとプラスに考えよう)
delegateでもinheritanceでも使えば良いんだけど、でも、プロトコル自体が安直なので、そうなってしまっているらしい。プロトコルの設計って、やっぱり、学生の手には負えないらしい。逆に、たこいプロトコルのたこい実装でも*動いている*ところは評価するべきか。
なんだけど、この実装だと、その部分を削除して掃除するところから始めないとだめか... まぁ、でも、4つか5つかだから。
他の部分は割りと良くできる。java.nioのSelectorとHandlerの部分とか。結構、うるさく言ったからなぁ。でも、Interface名とImplement class名に関連のない名前が付いているので、思わずgrepで探しちゃいました。Eclipseで、あるInterfaceを実装しているクラスを検索するなんて言うことも可能なのだろうとは思うんだけど、grepが楽。Java の名前付には英語的なセンスが必須。いや、nativeから見れば、どうせ変なんだろうけど。
でも、もう卒業しちゃったから文句も言えん。あ、でも、自分でハッシュテーブルに入れっぱなしで削除し忘れなんてのも見つけました。ひどい。誰だよ、こんなの書いたの。これじゃGCされないつうの。だから、自分です。ごめんなさい。
別な学生のRemote editorのJavaの実装では、一つのクラスのほとんどのメソッドの先頭に、
if (lock) { ...
がはさまっているなんてのも見ました。しかもお互いに呼びあってるし。「これって、さっきチェックしたから、ここで同じことをチェックする必要はないよね?」
というか、それは、State Patternを使う方が良いよな〜
でも、vim の方の実装だと同じことをやっていたような記憶もあるな。Cだったら良いのか? C で State Pattern は意外に面倒だからな。
