moxt

Just another Blog site

私は正しくないオブジェクト指向を体得しているエンジニアです

      2015/08/06

はじめに

自分語りをしたら終わりのクソブロガー問題です。

プログラミングはじめたばかりの頃から仕事でプログラミングを書き続けてきて、オブジェクト指向に対する考えがどのように変化していったのか振り返る。

大学生の自分とオブジェクト指向

オブジェクト指向という単語と出会ったのは大学の講義だ。

クラスは車の設計図で、オブジェクトは設計図を元に作った車だ。

みたいなアレ。
まずプログラミングに設計図(クラス)やらオブジェクトやらよく分からない考え方が出てきて拒絶反応を示していた。

今思えば、プログラミングについてまともに考えたこともないので、そりゃそうだろ。って感じ。

インタフェースとかも具体的なメソッドも無いんだから使い道無いでしょ、って思ったし。
MVCなんて考え方も知らないから、Viewにゴリゴリロジック書いてた気がする。
単純にプログラムを書く量が少なかった。
思考の分解も足りなかったから、適当にググったそれらしいコードをサルみたいにコピペしてた。
ネット上のサンプルコードは説明のためにViewにロジック書いたりしてる。
なので、コピペしてたらそりゃあスゴいコードになってゆく。

大学のプログラミング実習で簡単な買い物サイトをPHPで作ったり、Javaアプレットで簡単なゲームを作ったりした。
作りこむうちにむちゃくちゃなコードになってきて、アッチを直せばコッチが壊れるみたいな状況が茶飯事だった。
どうにかこうにか動くモノを提出して単位を掴みとった記憶がある。
そんな失敗体験もあってか、私生活では全くプログラムはやらなかったと思う。

就職するのが嫌で大学院に進学した。

大学生の自分とオブジェクト指向

大学院の講義でもプログラミングの課題があった。
やっぱり嫌々やっていたし、人に教えまくってもらってなんとか提出にこぎつけるって感じだった。
オブジェクト指向的な発想なんか皆無だったし、その時書いたプログラムを1週間後に見返してみたが自分でも何やってるかさっぱり分からなかった。。

HTML5がまだまだ広まる前の当時、フロントエンドの花型はまだまだFlashだった。
名の知れた会社のキャンペーンサイトはほぼフルFlashだった。
ああ、こりゃカッコいいと思ってFlashやProcessingといった見た目系プログラミングに傾倒する。
名前が全く思い出せないが、無償で使えるaction scriptのIDEが使えたのでそれを使って自分のイケてるサイトを作ろうとしていた。

見た目系プログラミングとなるといよいよオブジェクト指向的な発想が無いとダメだろ、思うかもしれない。
振り返るとその発想は全く無かった。

そもそも、クラスってのがよく分からなかったし、細かくクラスを作って処理を委譲させたりするのも億劫で1クラスにたくさん責務を詰め込んでいた。
それからActionScriptはシングルスレッドなのでメインスレッド内で重い処理(スゴいループとか)をさせると動作がカクカクする。
ただ、スレッドの概念もよく分かってなかったので別スレッドに処理を任せるとかじゃなくてスレッドで行う処理を謎に分割してカクカクさせないようにする、みたいな謎な行為をやってた。
相変わらずクソな感じだったが、なんだかんだそこそこ集中して取り組んでいたと思う。
書いたコードの量も増えてきた。

なんとか大学院を卒業して就職した。

社会人の自分とオブジェクト指向

そこはガチのエンジニアリングが求められていた。

けど、自分はサーバサイドの知識もロクにないし、PythonやPerl,Rubyといったスクリプト言語もガッツリ触ったことなかったので、ずっとフワフワしてた。
よく雇ってもらえたものだ。ラッキー(=^・^=)
研修でオブジェクト指向を講義してもらったりしたが、やっぱりここでもオブジェクト指向はなんか遠い存在だった。
現場では先人たちが作ってきたオブジェクトたちを駆使したり、改変したりして新しい機能を作ったりする必要があるんだけど、まあ、、よく分からない。
MVCに関する素養もなく、なぜこのコードはこのように書かれているのか、なんでこんなに色んなオブジェクトが出てくるのか、なんでこんなに細かくする必要があるのか、全く全く分かってなかった。
何も身についてないし、何も理解できない、絶望的だった。

先輩エンジニアに薦められた本を読んだ。
デザインパターン、リファクタリング、コードの書き方などの本を重点的に読んだ。
他人(未来の自分も含めて)と協調してプログラムを作っていくためには何が必要なのか、どんなことに注意を払うべきなのか、この辺の知識や意識ある実践が無かったことに気がつけた。

命名に時間をかける

自分の中での最初の変化は、変数やメソッド名前をつけるときに時間をかけるようになったことだ。
この変数名を読んだら人はどう思うだろう、自分だったらどう思うか、考えるようになった。
もちろん今でも完璧にできてるとは思わないし、迷うこともたくさんある。
今思い返すと『命名に時間をかける』ってのは大きな変化だったと思う。

お気に入りのデザインパターンを見つけた

次の変化はお気に入りのデザインパターンを見つけたこと。

2つある。

1つ。
ファサード、というパターンだ。
窓口という名前の通り、ファサードなオブジェクトに何かをお願いすれば(メソッドを呼ぶ)希望の処理が実行されたり、欲しいオブジェクトを返してくれるというモノ。
中では複雑な処理をしてるかもしれないが、客に対してその複雑な処理内容を意識させることは無い。
ATMみたいなもんでボタンをポチポチ押してれば簡単に誰かに送金できる。
中では両者の口座データベースを横断した複雑な処理が行われているが、ユーザはそんなことは知らない。
ただボタンをポチポチ押してるだけ。
あー、これはカッコいいわと思った。本当に。
処理を抽象化して、その抽象化された処理を組み合わせてさらに複雑な処理を実現する、そしてそれすらも抽象化されてゆく、という抽象化によって複雑な要件を飲み込んでゆく感じが無限の可能性を感じさせるからだ。

もう1つ。
出版-購読型モデル、パブサブモデルなんて名前で知った気がする。
GoFなデザインパターンではないのでアレかもしれないが、パブサブはかなりカッコいい。

先輩に教えてもらったパブサブモデルの例がスゴいわかりやすかったので盗用。

本を出版する人と、本を読む人がいる。

本を出版する人は本を書いて、本屋やらコンビニを媒介にして読者に届ける。
本を出版する人のやることは以上。

で、その本を読む人は本屋やらコンビニで購入して読むわけ。

本を読んだ人はそれぞれ

海賊王を目指したり、
漫画家を志したり、
やっぱ仲間って大事だよねとしんみりしたり、

と、行動(振る舞い)が違うのが自然なわけ。

出版社が読者の行動を決定するのではなく、本を読んだ読者自身が自分自身の行動を決めましょう。
と、いう話。

なので、出版社が読者の型(海賊王志向クラス、漫画家志望クラス、友情に熱いクラス)を見てそれぞれの行動を指示するのは普通に考えたらおかしい。
だって、読者の行動が出版社に依存してるから。
あくまで出版社は本を出版するだけで、その本を読んだ読者が何をするかという関心は出版社は持つ必要ない。
いやいや、そりゃあそうでしょ。
って、思う。
だけど、何も考えずにプログラム書いてると上のような出版社が読者の行動をコントロールするようなコードが完成したりする。

親の読者クラスは『本が出版された』というメッセージを受け取れるようにしておいて、具体的な子クラス(海賊王志向クラスとか)が振る舞いを実装するような感じ。

本を媒介にすることで両クラスが互いに無関心でいられることが良いなと思った。
無関心でいられれば、相手のクラスのことを考えずに自由に振る舞うことができる。

プログラムと無関心との関係

このあたりから『無関心』がプログラムを書く上では重要なのではないかと思い始める。
それまでインタフェースが何のために存在するか分からなかったが、無関心というキーワードとセットにして見返してみるとインタフェースは関心を減らすための仕掛けだと気がつく。

内部の複雑な実装を隠蔽して統一されたIN/OUTを表明させるのがインタフェース。
インタフェース同士を連結させることができれば、同じインタフェースを実装してる別のクラスに差し替えることも容易。
テスト用のモックに変えたり、有料課金ユーザ専用の機能制限を解除したクラスに差し替えたり、が簡単にできるのでプログラムに柔軟な振る舞いを与えることができる。

DI、依存性の注入なんて小難しい言葉で表現されてるモノも無関心を促進するための仕組み。
普段何気なく使ってるコンストラクタでDIを実践してる。

こういう奴。
コンストラクタに渡される引数はインタフェースになってると、気軽にEngineMock型に差し替えたり、HyperDashEngine型に変えられたりする。
ここの引数を具体的なクラスにしてしまうとそのクラスとベッタリ依存してしまいコンストラクタの旨味は享受できない。

何もできないインタフェースが何のために存在してるのかようやく理解できてきた。

この無関心を進めるとクラスは細かく分割されてゆくし、クラス同士を結合させるのではなくインタフェース同士を結合させるような作り方になってゆくと思う。

正しいオブジェクト指向ではないかもしれないが、ひとまず『無関心を追求する』で腑に落ちてる。

と、いって情報を取り入れるのをやめるのもアレなので、ThoughtWorksアンソロジーを読んだり、ただの枕になりかけてるエリック・エヴァンスのDDD本なんかと改めて向き合って、楽しくオブジェクト指向できるようになりたい。

 - Dregs

  • このエントリーをはてなブックマークに追加
  • follow us in feedly

  関連記事

no image
AV女優の名前の傾向調べた

周りの知り合いがちょいちょい親になってるんだけど、子供(女の子)の名前を考えるときAV女優の名前と重複してるか調べるらしい。 まあ、、なんとなく分かるわ。 …

no image
ファイルとかのパーミッションを再帰的に変更したい

あるディレクトリ以下全ファイルのパーミッションを再帰的に変更 chmod …

no image
なぜ人は『汚い言葉を使うと云々…』と言いたくなるのか

少し話題になっていたので便乗してしまった。 基本的にはしょうもない話。 …

no image
お笑い芸人とプログラミング

自分はとても小さな会社でエンジニアをやってる。 同僚と一緒に帰る途中にした会話がちょっとおもしろかったのでメモ。

no image
Androidアプリを作るために最低限必要な知識と未知の部分を列挙

作りたいアプリによって必要な知識は変わるかもしれないが。。 個人的過ぎて役に立たないが、整理がてら羅列してみる。 …