福冨諭の福冨論 / 長文記事

基礎の研究 - 応用の研究 - 実用

という3者のモデルでなんとなく考えていて、

基礎の研究 = 言語学
応用の研究 = 自然言語処理

という役割にはなってないんだろうなあと思ってみたりする。

一方、別の分野ではあるけれども、実用の現場での気付き・発見が
定量的な評価が難しいために基礎/応用の研究にフィードバックされなくて、
現場の人がくさってるという話があったりすることから考えて、
この場合も基礎の研究と応用の研究が噛み合ってないだけなのかなあという気もする。

そういえばクラスのメソッドの中だけで使える関数を作りたいと思うことはあるな。機能だけでいえば private なメソッドでいいんだけど、問題の場面から視線が動いてしまうことが嫌だし、その場所でしか使わない処理なのでクラス内のどこからでも呼べる private よりさらに制限をきつくしたい。無名関数でいいという説もあるけど、それなりに長い処理になってしまうとやはり可読性が落ちてしまう。そもそものクラス設計が適切であればそういう苦労もあまりしないんだうけど。

まあ継承に関しては「親クラスへの機能追加が頻繁に発生しないこと」が重要だと考えている。そのためには充分に枯れた概念(例えばWebのMVCフレームワーク)の実装だったり、
ごく限られた責務のみ実装していることが必要になると思うのだけど、後者を実現するためにはmixinとしての多重継承がないと実用的ではなさそう。

共通部分を親クラスにまとめようという発想は悪手。共通部分は必要に応じて増えていくものだし、共通だと思ったら実は例外があったりして複雑になる。具体例を挙げると、親クラスにメソッドを1つ追加するときには、全ての子クラスが同名のメソッドを持ってないことを確認する必要がある。

特定のプロダクト向けのライブラリ群、あるいはフレームワーク的なものを作って、どう育てていくかというに興味がある。というか、あった。改めて考えてみれば、そういうのが必要になったのは今まで関わってきたプロダクトが少々特殊で、データの持ち方が普通のRDBではないためActiveDirectory系統の技術が活用できないとか、簡単ログインや携帯の画面のためにコントローラの共通部分を厚くする必要があるとか、ビューの機能を厚くする必要があるとか、まあそういう事情があったわけだ。

そういう環境を離れてみると、枯れてる技術の組み合わせで多くのことが実現できるんだよね。そういう事情があってフレームワークを作っていくことにあまり興味がなくなってしまった。

一方で、パッケージソフトウェア的な方向に興味が出てきた。共通ライブラリを作って複数の場所で使うというのと実質的にはあまり変わらない気もするけど、1つのソフトウェアを作って複数の場所で設定だけ切り替えて使えればいいんじゃないかな、みたいな。そこまで一般化したソフトウェアの設計は困難だろうとは思うんだけど、まあやってみたい話ではある。

表に出てくるところが似ているとしても、その基となるところが異なることはあるし、それが異なるということに気付かないと判断を誤るよなー。人間でいえば動機とか。自分のことであっても気付かないことあるしね。ブログであれば書きたいことがあるから書いているのか、ブログの仕組みを運用したいから文章を作っているのか、とかとか。