ちゃんと書こうと思ったらまた果てしねぇ時間が溶けるので、さわり（広く芸能で、中心となる見どころ・聞きどころ。また、話や文章などで最も感動的、印象的な部分。）だけ書く。
◆おことわり
この記事は、意図的に何も見ず何も調べずに書いている。なぜなら際限がないと思ったから。一部リンクを張るためにググったのはあるけども。
調べずに書いたから俺の思い込みとかがふんだんにトッピングされていると思われる。間違っている可能性があるよ。カチンと来たらコメント欄で罵倒しよう。
◆なぜこの記事を書こうと思ったのか
オブジェクト指向について、初学者を対象にそれを説明している記事はほぼ全部クソカスである。何一つピンとくることはない。およそ前提から踏み間違えてるから後がすべて崩れている。
侍エンジニア塾はマジで社会を停滞させている業界のガンだから爆発して消滅しろっつって。
このあいだQiitaからメルマガが届いて、以下の記事がランキングに上がっていたことを知った。
なんかもう読みづれぇわ結論がおかしいわでな。こいつ何が言いてぇんだ。
◆オブジェクト指向というワード
プログラミングの初学者がオブジェクト指向というワードを聞いたときに思い浮かべるべきことは、オブジェクト指向プログラミングではない。オブジェクト指向言語です。
世間一般で喧伝されているオブジェクト指向プログラミングなるものについて悩んでも、今のテメーには無理。無理だし、そんなに考えなくてもいい。なぜならやってもうまあじが然程ないから。そっちは険しいルートだ。オブジェクト指向プログラミングから高みによじぼるのはなかなかに難しいぜ。
オブジェクト指向プログラミングを徹底しても、おそらく今のお前にはいいこと起こらない。まずはニュアンスを掴みなさいな。
▼オブジェクト指向言語
任意の言語において、扱うものの（ほぼ）すべてがオブジェクトであるとき、それはオブジェクト指向である。
語弊：オブジェクト指向言語であっても、機能としてメモリアクセスできるようなものもある。オブジェクト指向をうたいつつ他のパラダイムも扱える場合が多い。
オブジェクト指向言語でコードを組めば、オブジェクト以外使ってないわけだからオブジェクト指向プログラミングしたということになる。お前は恐らくオブジェクト指向プログラミングを既に完遂している。
オブジェクト指向プログラミングできてるかどうかとか、そういう話は終わってる。修了。次の話に進んでください。
▼なぜオブジェクト指向の言語が作られたのか
実行時に出現するすべてがオブジェクトだったら、取扱うものは全てオブジェクトだ。そこに一貫性を産み出せる。オブジェクト指向ではないC言語では、出てくるものがオブジェクトじゃない色々なものである。だから「これなに？」「どういう操作をこいつにできるんだ？」から始まるしドキュメントも追いづらく考えづらい。言語の開発者からしても設計しづらい。拡張しづらいゆえ柔軟性もない。
「じゃあもう全部オブジェクトってことで（半ギレ）」という判断は妥当。EverythingIsAnObjectにしちゃう判断は有り得る。ただし、考えやすくした対価としてパフォーマンスチューニングに限度が出てきたりする。トレードオフ。
オブジェクトに可能なことは限られているから分かりやすく、ルールがあるゆえにドキュメントも追いやすい。そして言語の開発者からしても合意を取りやすくて楽。オブジェクトを筋道として思考を進められる。
◆オブジェクト指向プログラミング
オブジェクト指向プログラミングという語が指すものは文脈によって違う。だからみんなそれぞれ別のことを重要だと思ってそれぞれの主張をしていて噛み合わない。空中戦ばかりで根本の話はあまりされない。オブジェクト指向の話をしながら、その次の話も同時にされてしまっている。だからオブジェクト指向が何なのかってわからなくなってくる。
オブジェクト指向プログラミングは別にクラスの存在を前提としない。なぜならオブジェクトにしか指向する必要がないから。クラスインターフェースもいらない。継承もいらない。ポリモーフィズムもいらない。デザインパターンもオブジェクト指向そのものとは密結合していない。
だから、それらのオプションについて語ったところでオブジェクト指向について語ったことにはならない。コーヒーを知りたい人がコーヒーについて調べようと思ってるのに、カプチーノのフォームミルクの泡立て方とか語られてもよくわからない。しらない。それカプチーノの話じゃんか。いやカプチーノの話でもないわ。フォームミルクの話だ。「カプチーノというコーヒーの飲み方にも利用できるフォームミルクのはなし」だ。コーヒーの話と一緒くたにすんなよ阿呆め。
みたいな。
オブジェクト同士でのメッセージングができなければオブジェクト指向とは言えない。メッセージングという手法に伴ってカプセル化は自ずと成される。オブジェクト指向の基本を語りながらメッセージング（メッセージパッシング）というワードが出てこない記事があったらそれはフェイク。
「フォームミルク」ってよく言われるけどあれ「フォームドミルク」あるいは「ミルクフォーム」じゃね？とずっと思っている。
オブジェクト指向プログラミングについてなんか複雑なことを言っている記事をみたら、スルーしてください。オブジェクト指向ではなくてオプションの話をしているだけです。
▼オブジェクトってなんなのか
状態を持ちながら相互に通信しあうもの。それがオブジェクト。
状態を持たなければオブジェクトではなく、相互にメッセージを通信しあわなければオブジェクトではない。
オブジェクトAからオブジェクトBへ一方的に通信しているかのように見える実装であっても、実態として相互通信せねばお互いの存在を認識できない。これも捉え方の話だが。
オブジェクトを抽象的に上手く扱いたかったから、各言語が周辺機能を充実させている。例えばその周辺機能のひとつがクラス。
極限まで攻めれば、サーバー1台にオブジェクトひとつが割り当たる。ソフトウェアプログラミングに限った話で言えばサーバーとか登場しないけど、オブジェクトはメッセージングによりサービスを提供しているからサーバーとの違いもそんなにない。仮想サーバーだ。
オブジェクトが親子関係を持っているような構造になることもあるけど、それも関連、relationでしかなく、オブジェクト同士で通信しあっていると捉えることができる。
▼オブジェクト指向プログラミングは衰退するのか？
全然しない。いま全盛のマイクロサービスだってオブジェクト指向プログラミングであると言える。「オブジェクト指向プログラミングは衰退する」とか、例えるなら「三幕構成は衰退する」と主張するようなもんだ。視点の置き場所により、あるシステム、あるプログラムはオブジェクト指向プログラミングされたと解釈することができる。
ただし、お前らがオブジェクト指向プログラミングだと思っている何か別のそれらは衰退もするだろうな。
◆余談
クラスベースのオブジェクト指向言語に於いては、クラスに頼ってはいけない。「困ったらクラスつくっとく」はダメ。
状態、すなわちステータスが増えれば増えるほどコードの可読性はぶっ壊れる。だからクラスをポコポコ生やすのはクソったれの所業です。そのクラスの必要性について悩むべき。
ただし、メッセージとして利用するための極々簡素なクラスを定義するのは幾らでもしてよい。そういうクラスから起こしたインスタンスは内容を書き換えてはいけない。不変に。immutableに。
メッセージとしてだけ使うクラスを明示的に定義できるようになりつつある。C#で言うところのrecordは2020年に用意された。
ほいで、オブジェクト間のメッセージングによる処理にそんな拘る必要もない。手続きを書け。クラスの中ではstaticな（状態にアクセスしない）関数をたくさん用意してデータを処理しろ。パイプラインのように処理しろ。
◆抽象化
Qiitaの元記事書いた奴は抽象化に良くないイメージを持ってるように読めるんだが、ソフトウェアアーキテクチャの設計って抽象化仕事だろが。
物事のインターフェースを決めることは抽象化だ。抽象化の気持ちがないコードってなんだよ。アセンブラか？
APIの口。メソッドの引数。関数の引数。データ。命名。そこを正すために抽象化しまくれ。俺がコードを書いては潰し書いては潰しの反復横跳びをしているのは、俺の頭が悪いってこともあるけど、抽象と具象を行ったり来たりすることで一番ちょうどいい設計を探してるんだよ。
「カプセル化が悪い」とかの世迷言も書いてるけど、それクラサバを否定してるようなもんですからね。対向サーバーの内部処理になんざ関与したくないわ絶対に。堅牢なインターフェースだけ用意してくれろ。
▼違うものは違く扱え
余談：違くない？ | ことば（放送用語） – 最近気になる放送用語 | NHK放送文化研究所
「処理を共通化（再利用）したいからインターフェースを共通化する」みたいな誤解はありがち。それも抽象化といえば抽象化だけど、人の都合が滲んでるから歪な形にもなるわ。
違うものは違う扱いをせねばならない。キュウリとちんちんは棒状という抽象を持ちつつも違うものだから、ちんちんをキュウリのように扱うと事故が起きる。同じものだけ同じ扱いができるよう抽象化しろ。
抽象化した結果違う概念であったら、それは同じ抽象グループ（？）にまとめてはいけない。
勘に頼らざるを得ない部分も大きいけどな。「抽象化しなかった結果ひどい目にあった」「異なるものを都合で無理に抽象化したからひどい目にあった」って経験のどっちもある。食らったら反省して次に生かすしかない。
抽象化を詰めるにせよ詰めないにせよ、扱おうとしている概念がなんであるのかはよくよく見定める必要がある。もらった仕様や発想をそのまま実装しないでね。疑ってね。
◆結
この程度にしておく。あとは自分で何とかしろ。帰れ。
コメントを残す