こんにちは。
最近までC#はLivet+ReactivePropertyで開発をしていたのですが、全社的に使用しているフレームワークがPrismという事でPrismの勉強をしています。
余談ですが社内でReactivePropertyを知っていて、実際に使っているのは入社数年目の私だけかもしれません(知っている方はいた)。
でもPrismって結構面白い考え方なので、フレームワークとして好きになりそうです。
私もプログラミングを生業としてから数年しか経っていないペーペーですが、Prismを勉強していて
「オブジェクト指向について語るのであれば、Prismを勉強すれば良くない？」
と感じてしまいました。
Contents
オブジェクト指向＝神格化された概念
入社してすぐに上司に言われたことが「オブジェクト指向を…」でした。
それまでプログラミングなどしたことない私は、何が何やら状態でした。
オブジェクト指向という言葉、「これができないとプログラミングが」って感じで語られるのですが、本当にそうなのでしょうか？
最初は「オブジェクト指向に沿って設計・実装することが一番や…」って思っていました(そう思わざるをえない環境であった)。
そして、入社してまず渡された本が「オブジェクト指向方法論 OMT」でした。
手にしたことがある方はわかると思いますが、そこそこボリュームがあります。
今思えば、この本は入社してすぐに読ませるような本ではなかったと感じます。
オブジェクト指向は適用しようと思えばプログラミング以外の色々なものに使えそうですが、プログラミングをする上ではやはり成果物あっての話だと思います。
初心者がFormでプログラムを作成するとき、Formに2万行書いてあるのか、きちんと設計された上でグルーピングされて(あえてカプセル化とは言わない)2万行書いてあるか、どちらが実際に読みやすいかは実際に手を入れてみないとわからないのです。
オブジェクト指向とは、重要な考え方でありながら、プログラマの間では唯一神の様に語られる概念だと思っています。
私を含めてですが、オブジェクト指向は？と聞かれて聞いた人が腑に落ちるような解答を返せる方は少ないでしょう。
理由は簡単で「答えも実体もないものを見せて」と言われているので、それを具現化する事は難しいからです。
逆に言えば具現化さえしていれば伝えられるはずなので、やはりプログラミングにおいては具現化された成果物(コード)がないと難しいかな、と感じます。
オブジェクト指向という言葉が出てくると必ず「カプセル化」「多態性」「継承」と続きますが、とりあえず無視した方がいいかな、と思っています。
オブジェクトは最適化された結果である
私もコードを書き始めてまだ数年のペーペーのペーですが、書いていると
「これ、ここに書いていいのか？」
「何かが足りないな」
と感じることが出てきます。
このような思考を持ってやっていると
「このクラスに不要なやつ、足りないやつはいないか」
と最適化しようという思考が働いてきます。
この結果、オブジェクト指向という考え方にたどり着くのではないかと思います。
そもそも
「動けばいいやー」
「自分だけわかればいいやー」
と考えて実装している人間に「オブジェクト指向とは」と説いたところで糞の役にも立ちません。
動くだけ、読むだけであればオブジェクト指向とは関係がありませんからね。
Prismの、Moduleの集合でプログラムを作るという考え方
で、話は戻りますがPrismではModuleの集合によってプログラムを形成します。
このModuleが、オブジェクトに当たるのかな、と思っています。
イメージとしては「超強力な万能薬を作るのに、それぞれの効能に特化した薬を沢山用意して、上手く調合する」感じでしょうか。
それぞれの効能に特化した薬が、オブジェクトでありModuleであります。
なので「この効能が欲しいな」と思ったらその効能に特化した薬を別で作り、調合する部分が上手く調合してやればいいのです。
プログラムでは疎結合という言葉をよく耳にしますが、この考え方は非常に重要だと思います。
今の薬の例でいうならば「解熱と整腸効果のある薬」を1つ作るより、「解熱効果のある薬」と「整腸効果のある薬」を1つずつ別々で作った方がよいという事です。
前者を作ってしまうと、お互いがお互いに作用しあっているため、「解熱成分だけ欲しい」となったときに分離する手間が(思っている以上に)かかるからです。
この辺も語るより、実際に前者を作らせて「じゃ、それ分離して別々で使えるようにして」って鬼の様な事をやらせた方が早いかもしれません。
Prismは大規模なソフトウェア開発で使われますが、このModuleの設計＝カプセル化もといオブジェクト指向ができていないと全く効果を発揮しません。
なので良い設計、Prismでの実装を勉強させることが、オブジェクト指向の理解において強いのではないかと思います。
大事な事なので何度も言いますが、良い設計でないとダメです。
ここでいう良い設計がオブジェクト指向を体現するために必須で、それを可視化し、理解の助けをするのがPrismではないかと感じました。
Prismでなくとも、良い設計ができていれば理解できる！という意見もあるかと思いますが、私は今まで出会った事がないのです。
社内で開発された、大規模なソフトウェアのコードもいくつか見ましたが、正直全く読めませんでした。
しかしながら、練りに練った設計を、あそこまで疎結合で実現可能にさせるPrismというフレームワークはおそるべし、と感じてしまいました。
というより「これこそが良い設計というもんやで！」と自信を持って提示されてこなかったことが問題な気もしますけどね。
レガシーコードであれ、なんであれ、ソフトウェア開発を生業としている以上、自分のものであれ、他人のものであれ、自信を持って
「この設計は良い設計だ」
と、説明するための材料は欲しいと思いました。
良いものを食べている人は舌が肥える、じゃないですが、良い設計をするためには良い設計をしる必要があり、良い設計が良い設計たるゆえんを理解するにはPrismが良いのかな、と思いました。
コメント