@2018/10/18 - オブジェクト指向への懐疑心

#diary

今日はナレッジベースについてヒアリングを行った。

結構みんな前のめりになる話だったらしく、なかなかおもしろい意見を聞けた。

来週ブレストがあるのでそこで発散してできれば集約に持っていきたい。

さて、今日はオブジェクト指向と関数型の記事を読んだ。

Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。

関数型について無知なのでどこまで正しいことを言っているのかわからないけど、

オブジェクト指向への懐疑的な意見については概ね賛成できる。

オブジェクト指向では複雑性を扱うために状態を隠蔽する

裏を返せば外から見ると何をやっているのかわからない(だから命名が大事だの単語選択のセンスだのが大事と言われる)。

オブジェクト指向時代に生まれた設計指針は、むしろ過剰な構造化を誘発して、可読性や柔軟性を欠いたコードになることが多いのではないか

構造化＝設計といろいろな本や記事に書いてあるけど、いまだに「それホントに実現できるの？」と思うことがあるけど、同じこと言ってる。

そもそもオブジェクト指向が想定する抽象化が容易ではない

抽象化が容易でないのに、オブジェクト指向の設計指針には、その分割が本当に必要だと確信できるより前に、プログラムの分割を進めさせてしまうような圧力があります。

これもわかる。なんか構造化して分割してそれをピタゴラスイッチ的に動かすのがいい実装！な風潮、めっちゃある。

そもそも適切な抽象化が難しいのに、その抽象化が有用であるという証拠が揃わない内に分割を進めてしまうと、より不適切な分割をしてしまう可能性が高くなってしまいます。先走って分割したモジュールが、後々の状況変化に対応できなくなって、例外条件に対応するコードが増えて行き、そしてスパゲッティ化していく過程というのはシステム開発の現場で働く多くの人が目撃しているのではないでしょうか。

うっ・・・まぁここまでひどくなる前に最適な抽象化を諦めることが多いけどｗ

設計判断の根拠となる「スコープが適切でない」ということを、後から文脈をズラすことでいくらでも言えてしまうというのが問題の本質じゃないか、そこに「データ・ロジック一体型設計」の限界があるということなのではないか

そう、あとから見ると、ここは抽象化すべきだったなとか、まとめるべきだったなとかいろいろ出てくるんだよね。設計や実装を進めていく中で発見することも多いし。

オブジェクト指向というのは、オブジェクト指向にしかない問題を作り上げて、それを解決するためのツールを作るというマッチポンプ的なことをしてお金を稼いでいるという話があります。

まぁこれを疑いたくなる気持ちはわかるけど、ここまでは思わないかなー。関数型が完璧だとも思わないし、結局まだ歴史の浅い学問だから、というところに行き着くんじゃないかな。

もうちょっとしたら新しいパラダイムが発見されて、それを使い倒して批判されて・・・他の学問のように進んでくんじゃなかろうか。

とりあえずオブジェクト指向一辺倒で他を吟味しないのはもったいないからどこかで経験する機会を作らないとな。社内の勉強会のネタにしてもいいし。

いきなりアウトプットでもいいけど、インプットも最低限はやっておきたいから本でも読んでみるか。そんで年末年始の空き時間にでもなんか作ってみるかなー。

あとはまだ読めてないけど、以下のブログとか読んでみる。

「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～

また、このブログからのリンクで気になったページをまとめておく。

DCI Tokyo 2