オブジェクト指向のコードにあまりいい思い出が無い
Mijikko.icon from 2026/01/16
オブジェクト指向を学ぶべきだという主張を見かける度、オブジェクト指向の何がそんなにいいんだと首を傾げてる
オブジェクト指向に則ったソースコード、下手くそが多いだけでまともなのもあるんだろうけど
大抵は下のようなのがあるイメージ
無駄な継承
車輪の再発明
抽象化不足
汎用化不足
汎用化しすぎも工数的にはよくないけど
不必要なスコープの壁
汎用化不足にも関連する
アンチパターンとかコードの臭いとか呼ばれているやつ suto3.icon
継承とかいうシステム、あまりにも高度過ぎてほとんどの人はまともに扱えない
僕もよくわかってない内の1人Mijikko.icon
関係が複雑になってくると継承つらい、継承より合成にしてほしいyosider.icon
関数全部staticにしてくれ
カプセル化することによって特段便利になるやつ(≒個別の状態管理が必須なやつ)以外は
変更しやすくできるsta.icon
いわゆる技術的負債を減らせる
「概念」に依存させることを徹底することで、具体的実装への依存がなくなり各々独立してつくれるようになる
インタフェースと呼ばれるやつ
インターフェースまで参戦してくると考え方がよりややこしくなるやつMijikko.icon
この辺りに関してはまず処理の「変更」と「追加」を明確に分けるべきだと思うMijikko.icon
個人的な意見としては
変更
既存コード(クラスの場合は継承元のメソッド等)を書き換える(オーバーライドとか)
継承元の設計がしっかりしていないと、コード解析するのが非常に辛い
継承元の処理に別の処理を密結合で組み込むことになるから
状態(変数)の遷移、処理の流れ等を複数コードに渡って監視しなければならなくなり、デバッガーが必須になる
設計が間違ってたことが分かったときに気軽に変えられない環境だとつらそうyosider.icon
追加
既存コードに処理を追加する
イベントとかコールバック関数とかが該当
コード解析の際は追加されたコードのみ読めば良いことも多い
もちろん、実装者側の疎結合意識は必要
個人的にはむしろ、「コア部分は変更できなくした方が良い」と考えているMijikko.icon
部分的にpublicやprivateにするんじゃなくて
変更されたくないものは全部private
スコープ用語で言ったけど、JavaScript等では関数内のローカル変数のように、(敢えて出さない限り)実質外からアクセスできないものも指してる
変更されてもいいやつは汎用化して外に出す(疎結合化)
思ったことちょっと書いてみたけど、言語化と切り分けがむずい
自分で書いててあれだけど、観点が色々ごっちゃになってる感
書き方の問題なのか
考え方の問題なのか
言語仕様の問題なのか
クラス関係の言語仕様は現代の高度なシステムでも用いられているだけあって、流石にできないことはほとんどない
なので、多分気になることとしては、何でもできすぎるのはむしろ臭くないコードの実装難易度を上げてないかってとこになりそう
このあたり整理して機会があればもう一回ページ書き直してもいいかもしれない
20年前は有用だったが、2026年現在はこだわらなくても良いって思ってるtaktamur.iconMijikko.icon
当時からはハードもソフトも考え方も進化してる
そんな中、Smalltalk系のOOPは今でも異彩を放ってると思うから、触ってみると面白いと思う
↑野生のオブジェクト志向って感じてる
可読性という意味では現在でも最強だと思っているsta.icon
まあ複数人開発だと解釈の違いでろくなことにならないが
結局ドメインをどう理解してどう解釈するか次第
うまく言えないsta.icon
なんていうか、開発は「硬い仕事」だけど、OOPで設計する部分は「やわらかい仕事」になるというか
プログラミングというより概念創作
ぴったりハマるクラス構造や名前を思いつくとテンションアガるtaktamur.iconyosider.icon
うまく設計できていれば現実のアナロジーでコードを読めるので嬉しいyosider.icon
あるべきものがあるべきところにある
class の使い道が多すぎて、使い方を間違えることができてしまうSummer498.icon
=同じ名前(class)で異なるものを表せてしまうせいで運用間違いが生じる
関連する変数を纏めたいだけだから class にする
→実質 structure
関連する処理を纏めたいだけだから class にする
static メソッドの集まり
各インスタンスに状態を持たせたいから class にする
本質的に class
クラス無しで動くものを実装して、ある程度溜まってきたら整理してクラス化すると良いだろうSummer498.icon
なんせ似たものを集めて名前をつけることこそ類型化(classification)なのだから
昔、インターフェースは界面と訳す案があった筈
流行らんかったけど
https://ja.wikipedia.org/wiki/界面
ホンマに界面と interface の対応あるんか
ここで驚いているのは界面活性剤の界面が英語でinterfaceだったということに対して。
コンピュータ用語のinterfaceに界面ってつけても訳語揺れしなくなる。やったー
オブジェクト指向分析設計
オブジェクト指向プログラミング