開放閉鎖原則(open-closed-principle)ってもはや意味ない - きしだのHatena

SOLID原則というのがあるのだけど、原則といつつ やりすぎに注意なみたいなことを言われ、自分で塩梅を探らないといけないなら全然原則じゃないやんということであまり好きではないのだけど、その中でもここではOにあてはまる開放閉鎖原則って意味ないよねって話を。 開放閉鎖原則の原典はメイヤーの「オブジェクト指向入門」で、第2版には次のような記述があります。(初版も書いてることはだいたい同じで、2版のほうが整理されて記述も多くなってます) モジュールは開いていると同時に閉じているべきである ただ、このメイヤーの文脈でいうようなモジュールの拡張ってやらないよねと。 ここでメイヤーの文脈での拡張というのは、モジュール自体に手をいれずに、機能の追加や変更ができるというものです。継承使っていい感じに機能追加ができる設計が「拡張に開かれている」ということです。 でもまあ、そんなライブラリの拡張をやらないですよ

[p_tan]

開放閉鎖原則って、ソート関数に比較関数渡せるようにするとかが具体例だと思ってるので、重要ではなかろうか。最近の例だとLLMモデルの仕様が決まっててOllamaで好きに切り替えられるのもOCPの具体例じゃないのかな

[manaten]

こと業務アプリケーションにおいて継承による拡張が有効な業務の抽象化として働くケースがそんなにないのよな。

[s-nanagi]

よくあるタイプのWeb開発業務でOCPがぴったりなケースが比較的特殊で概ねYAGNIだよねというのは分からなくもない。でもシグネチャの変更コストが高い時の普遍的な話としてはOCPは機能していそうに見える。

[inm7tehepero]

自分の思いこんだ狭いコンテクストで適当なことを言わないでほしい。ライブラリやFW、モジュール、関数、マイクロサービスにしても機能追加や修正のたびに破壊的な変更をすることしか出来ない設計が是と言いたいの？

[sawat]

この辺、「継承を多用する設計における原則」みたいな話で、「継承ってそんなに多用するもんじゃねぇな」ってなった時点で前提が違ってるんじゃないかと思う

[devorgachem]

反対。現在の開発パラダイムは結合バグに脆弱でこの原則を守らないスタイルは結合バグを増やしがち。未来に渡ってコンポーネントのすべての利用者がその変更を必要としない限り元をいじるべきではない(文字数

[wwolf]

開放・閉鎖原則を語る時、メイヤーの方で言及するの自体が珍しい気がする。大体マーチンのインターフェイス使おうねの文脈で語ってると思う。名前重複してんじゃねぇという話なら分かる。

[strawberryhunter]

継承に限定すれば主張は正しいのだけど、現代的な解釈ではOCPは委譲、DI、プラグインも含んで良いはず。あらゆる拡張を想定することは不可能なので、想定の範囲内でYAGNIとバランスを取れって話に落ち着くだろう。

[mynz]

open-closed-principal って puig-in とか add-on の実現みたなことで、そこら辺に多用されてるんとちゃうんかと。

[matarillo]

SOLIDはソリッド（確固たるもの）ではない https://gist.github.com/matarillo/800c7f827602173eba6753f7e4039186#file-2_ocp-md

[gonerdog]

メイヤーがOCPを実現する方法として継承を使ってて現代的じゃないよねって話ならわかる。けどその実現方法を根拠にOCP不要説を唱えるのは無理があるかな。現代ではより疎結合にOCPを実現する方法があるので試してみては

[longyang]

誰かの発言を見る時、対象がどの程度の範囲に及ぶのかが分からないまま過剰に反応してもな、と良く思うので、その辺をAIが補完してくれると記事に左右されにくい穏やかな生活になるような気がしている。

[secseek]

できるかどうかはともかく理想としてあるべきだよねって話はあっていいと思います。さすがにその辺の価値観が存在すらしていない人だと会話が成り立たないので

[mas-higa]

"複数ユーザー向けに異なる機能を提供するシチュエーションがあるかというとないですね" 自社のアプリをカスタマイズして売るような商売してれば頻繁にあるでしょう。まぁそれを継承ではやらんけど。

[paulownia]

「狭い世界で語るな」という厳しいコメントがあるが、同意せざるを得ない。別チームが作ったライブラリの使用を強制され、修正が許可されてないという状況は今でもあり、そのライブラリが拡張に開かれてないと詰む

[noname774300]

他ブコメリンク先の『SOLID原則はソリッドではない』はめっちゃいい文章。ていうかdeprecated、obsoletedとかよく見るし、結果的に原則が破られていることは多い。 https://gist.github.com/matarillo/800c7f827602173eba6753f7e4039186

[takahashim]

現代的に一般化されたOCPは「第三者が作ったモジュールを拡張したい」という要望を持つモジュール利用者に対してどう利用しやすいものを提供するか、という話だと思ってます。forkもアリだけど運用コストがでかい

[slack_pulse]

“まだ見ぬ拡張に対応するような設計が本当に必要かというのもある” どこかに書いてあった気がしたが忘れたというのは悪いので探したところ アジャイルソフトウエア開発の奥義p.117 に似たような事が書いてあった

[atsushieno]

IDEやブラウザのアドインを開発していれば「バージョンが上がって互換性がなくなりました。でも自分でソースいじれば動くようにできるから問題なよね」では困るし、それはカプセル化では解決しないと考えるのでは

[Error401]

OCPに限らずSOLIDインストール後は「だいたい抽象に対して実装すればいいんでしょ」的な思考に落ちつくと思うけど、あえてOCPは不要という意味もないと思う。

[sa-yama321]

役に立つ原則もあるけど、SOLIDは広まっているのに意味がない原則のひとつだと思うわ。

[suginoy]

自分は原則ではなく達成目標だと思ってる。

[hogeaegxa]

継承絡みでなく簡単に見える単一責任原則も、正しいことは直感でわかるが、実践するとすぐに無思考で簡単にパターンを当てはめられる代物ではないのがわかるからな。原則すら全部に適用できる銀の弾丸ではないのだ。

[fuji_haruka]

メイヤーの原典にあたっててえらい

[yojik]

作ろうとしているモノによる。例えばエディタをつくってるなら絶対に必要だし、マイクロサービスが連携する業務システムならそもそも原則の適用範囲から外れてる。つまり時代は関係ないのでは。。

[anqmb]

「まだ見ぬ拡張に対応するような設計が本当に必要かというのもある。だいたい、無用に複雑になり、作業の邪魔になることはあっても、その複雑さが報われることはない」

[ghostbass]

多分 principal > principle の typo / 一人二人でやってるなら別にどうってことはないけど規模が大きくなると「ああ、あそこ引数追加したから」で死ねる局面は意外とありそうな。

[PrivateIntMain]

アーキテクチャから内部に至るまでインターフェースまみれな昨今は、Sを満たせば他は特に考えなくていいとも言えるかもしれない？

[objectiveworker]

普通のアプリ開発でフレームワークなんて作らない方がいいと思う。

[AtsukoMay]

原則だったらprinciple だとおもうんだけど、と思ってぐぐってしまったわ。内容のことじゃなくてごめんね。

[uehaj]

セマンティックバージョニングがこの問題を解決している気もする。互換性は壊さなきゃいけないときは壊すべきで、無理に抗うと汚くなり壊れる。でも互換性のなさを明示することで実害を低減する。あとcodemodとかね

[gonta616]

オブジェクトの継承や中で分岐書くのではなく、インターフェイスとコンポジションの組み合わせで、拡張には開いてて、変更には閉じてる話だと理解してるし、非常に有効と認識してる

[prograti]

Event Busとかよく使うけどああいうのはOCPとは言わないのかな？

[toropicana7x]

継承に固執した古典的解釈と現代の抽象化プラクティスを混同し、OCPの本質的な価値（変更の局所化）を見落としている

[turanukimaru]

例えば書籍アプリを作る場合、複数の出版社や取次、映像やゲーム会社とのキャンペーンの連携なんかが発生するので閉じてないとすぐクソコードになる。内部データ構造にせず出版社ごとにテーブルを作ったりとかね。

[trace22]

「原則」として学ぶ必要がないというのならば同意。その発想をなくすべきであるというのならば反対。

[henno]

開いてるのに閉じてるってオートポイエーシスかよ（かよ）