オブジェクト指向の呪いと、その避け方 - mizchi's blog

このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品...

記事へジャンプ

みんなの反応

はてなブックマークでの反応
1oukayuka@hatena 2018/07/31 13:12
Martin Fowler の JavaScript 版『Refactoring』の1日も早い出版が望まれる。 https://bit.ly/2LH20xO
2murishinai@hatena 2018/07/31 13:18
参考書籍、英語なら公式でwebでよめる http://gameprogrammingpatterns.com/contents.html
3katzchang@hatena 2018/07/31 13:24
高階関数はなー、結局DIとやってること変わらないと思う
4fujimuradaisuke@hatena 2018/07/31 13:28
Validator.new.validate とか Service.new.performとか、Railsでもよく見る。ただの副作用のある関数なのになぜかクラスになっていて気持ち悪い
5fushiroyama@hatena 2018/07/31 13:44
オブジェクトの雛形としてのクラスは不要で型としてのクラスは依然意味を持つ、つまりHaskell最強ということですね?(本文を読んでいない)
6likr@hatena 2018/07/31 14:00
validatorみたいなロジックに状態はあってもいいと思うので、「階層化されたツリー構造に埋め込まれる状態」の方を詳しく聞いてみたい
7naofumi-fujii@hatena 2018/07/31 14:04
“ファイッ”
8wordi@hatena 2018/07/31 14:27
何でもありの動的型付け言語は論外として、ダックタイピング・ジェネリクスの出来ない言語で継承無しのデザインパターンってどうするのか気になる
9soy-curd@hatena 2018/07/31 14:36
“階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない”
10koroharo@hatena 2018/07/31 14:39
“階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。”
11ledsun@hatena 2018/07/31 14:40
概ね同意。批判するとしたらタイトル。「オブジェクト指向の呪い」より「クラス指向の呪い」の方が内容と合う気がする(オブジェクト指向の呪いの方が遠くまで届くと思います)。
12programmablekinoko@hatena 2018/07/31 14:59
「名前空間がほしいだけのクラスも不要」 はい
13arvelt@hatena 2018/07/31 15:00
“Game Programming Patterns”
14atwata@hatena 2018/07/31 15:11
脊髄反射でイラッとしたけど読んだら納得させられた
15dexia2@hatena 2018/07/31 15:18
見ていてすごく慎重な書き方をされているなと感じます。スコープをJavaScriptに限定していたり、継承もよい場合があるとか、理由もない場合は駄目とか。/このスコープなら概ね正しいんだろうなと思います。
16gowithyou@hatena 2018/07/31 15:23
この人JavaScriptしかできないの?
17thesecret3@hatena 2018/07/31 15:35
UMLのような設計というのは世間ではもうやらないものなんだろか?
18sugar_affordance@hatena 2018/07/31 15:38
パンピーエンジニアにとっては徳の高すぎる内容なのでまずこれを理解できる人を周りからピックアップするところから始めます / スターつけないでくださいしんでしまいます
19dalmacija@hatena 2018/07/31 15:51
今の凡人戦線は宣言的に書いたほうがいいところを手続きで書くなあたりで、ある時期JavaとC++の言語仕様と同一視された「オブジェクト指向」の不幸はパラダイムの抽象理解ができない人がいる限り繰り返す。かな
20nisisinjuku@hatena 2018/07/31 15:55
φ(..)メモメモ
21onigra@hatena 2018/07/31 15:57
JavaScriptのclassは正直使っていいのか悪いのかよくわからんと思いながら書いてる
22circled@hatena 2018/07/31 16:04
一方Appleはプロトコル指向を提案した。
23n314@hatena 2018/07/31 16:19
データと処理をクラスにまとめないなら部分適用は言語機能として欲しいところ。最初に難解な型を設計するか、難しさはそこそこのオブジェクト指向で後になって複雑さに悩むか、困難さをいつ引き受けるかだよなあ。
24satomi_hanten@hatena 2018/07/31 16:31
主旨には同意。「最適化には早すぎる」はそうかなぁ、という感想。もう少しファッションでコンパイラ書けると良いんだけど。言語デザイナとパタンナがオブジェクト指向から抜けてないと意味が無いし。
25erukiti@hatena 2018/07/31 16:49
Javaめいた過剰なOOPっぽいコードは明らかにバッドパターンよねぇ。単なる関数で済むならそれに超したことは無い / GoFも既に今の時代では半分害悪に成り下がってるよなぁ
26ykonomin@hatena 2018/07/31 16:52
行動力の化身
27foobarchocobo@hatena 2018/07/31 16:59
Smalltalkは美しかったのにピャー何とかは癌と変わらん実装だと当時思ってた。何より言語仕様に付いてこれるPGが未だに欠片しかいない
28mexxx@hatena 2018/07/31 17:06
「RailsのController 継承は悩ましくて、認証漏れを起こす」とあるけど、シチュエーションが理解できない。ApplicationControllerのbefore_actionで認証処理を書いて、認証が不要なコントローラーではそれskipするのが普通じゃないの?
29SHAKEII@hatena 2018/07/31 17:19
信念があって良い
30umai_bow@hatena 2018/07/31 17:26
「ミュータブルやめろ」を具体例に直しただけでは
31zyzy@hatena 2018/07/31 17:48
大体Javaが作り出した悪習っていう(更に言うとC++もだが)
32morita_non@hatena 2018/07/31 18:02
javaはもちろん、もはやjsでやる意味もないという。
33fuji_haruka@hatena 2018/07/31 18:22
うっすら似たようなこと考えてたけど言語化力がすごい
34innx_hidenori@hatena 2018/07/31 18:28
昔はワケの分からん継承ツリーを作って自己満足してたなあ。
35megumin1@hatena 2018/07/31 18:32
一般にJavaScript以外の経験が浅い人がこういうことを語るときは、やはり不備が目立つますね。 「コンポジションの手段として Scala では trait...」 <-- 違うと思いますよ。これらを使用した経験が浅いのではないでしょうか?
36gabari@hatena 2018/07/31 18:41
「状態はわれ窓」似たようなことを思ってた時はあるけど.Netの本 https://amazon.jp/dp/B01BD9MTN2/ に「初心者にはその方が分かりやすい」と書いてあってそういうもんだと思うようにしている。ちなみに良書。
37aquarickn@hatena 2018/07/31 18:42
魂震えてるじゃん
38comp123jp@hatena 2018/07/31 18:50
java,eclipseに限った話どけど、関数の実装見たくてf3押すとインターフェースが出てくるの何とかして欲しい。ここでどんな動作するのか見たいのに・・・。
39te2u@hatena 2018/07/31 18:50
今Haskellを学習しているというのもあるが、思うのは状態と副作用をいかに明確に示すかという点。これらは暗黙的に定義される傾向があり、わかりにくさにつながる。これはOOPというより手続き型言語に対する印象。
40uehaj@hatena 2018/07/31 19:14
オブジェクト指向は現実世界を近似しようとする。現実世界は制御可能とは限らない副作用だらけの一回切りの非決定論の世界。と言うのがもっと根本にあると思っている
41kastro-iyan@hatena 2018/07/31 19:18
全然分からなかったけど、多重継承がクソって話?
42nida3001@hatena 2018/07/31 19:26
オブジェクトの呪い、thisの呪い、アロー関数の呪い
43knknkn11626@hatena 2018/07/31 19:31
https://github.com/nslocum/design-patterns-in-ruby 読んだら?
44razokulover@hatena 2018/07/31 19:37
わかり
45ch1248@hatena 2018/07/31 19:39
論旨に同意。OOにおいてクラスはあくまで代替品であるし、継承やSingletonはあくまで必要悪であり密結合の権化なので排除されて然るべき。
46iTaro@hatena 2018/07/31 19:47
モノリシックな巨大システムではSOLID原則に忠実な設計の方が望ましく、マイクロサービス的なシステムでは関数型言語によるアプローチの方が望ましいと思う。唯一にして最良の手段はなく、使い分けでないかなぁ
47KoshianX@hatena 2018/07/31 19:50
オブジェクト指向は呪い。まあそうかもなあ。いまはいろんなものが抽象化されててオブジェクト指向に頼らなくても書けるようになってきて、むしろ邪魔になってきたというのもあるんじゃないかという気はしなくもない
48Haaaa_N@hatena 2018/07/31 20:01
わかる,わかるのだが,コードがコピペされていてコピペよりは継承のほうがマシというケースが多々あり,合成に直している暇も無かったりする
49rizmhate@hatena 2018/07/31 20:06
大規模開発では、しばらくはいままでのOOPで良いと思う。
50ebibibi@hatena 2018/07/31 20:09
最近はこんな感じですか。この辺りに関しての自分の認識は20年前でストップしてるので、ちょっとヤバさを感じますね…。
51quick_past@hatena 2018/07/31 20:09
それ別にオブジェクト指向の問題ではないんでは。
52nakag0711@hatena 2018/07/31 20:23
全てのセッターで全部のプロパティを列挙するのはいやだなあ
53teruroom@hatena 2018/07/31 20:30
トレイトをミックスインしたらクラスの継承はいらない気がする。さらに、高階関数を使うとクラスに従属するメソッドとかほとんど必要なくなる気がする。
54mag4n@hatena 2018/07/31 20:31
継承の鬼のようなAS3という言語が古くはあるけど、あれはだいぶ特殊なのだろうか…
55tonkotsuboy_com@hatena 2018/07/31 20:40
staticおじさんとコンピュータおばあちゃんが夫婦なのは、意外に知られていない。
56quabbin@hatena 2018/07/31 20:46
Validatorをクラス化するのは、ドメイン化をはかる目的が強いので、切り捨てるのは違うなぁと感じるが、そういや世の中にそういうコードはあまり放流されてないのだった。放流するべかなぁ
57koba789@hatena 2018/07/31 20:49
Game Programming Patterns は最高の本なので絶対に読んでほしい
58eerga@hatena 2018/07/31 20:54
gof全盛期でも継承より委譲じゃなかったっけ?
59zetta1985@hatena 2018/07/31 20:58
Game Programming Patterns 読んだけど、そんなに強烈な印象持たなかったなぁ。良い本であることは確かだけど
60iincho_jp@hatena 2018/07/31 20:59
Objective-c -> Swift移行後、protocolベースの実装できるようになり継承から開放されて今は幸せです。
61haruharu1@hatena 2018/07/31 21:06
継承のことは嫌いでもオブジェクト指向のことは嫌いにならないでください!!!!!┐( ∵ )┌
62iww@hatena 2018/07/31 21:20
『基本的には、「継承よりコンポジション」です。 それでもやらないといけないとしたら、ストラテジーパターンを想定したライブラリから、一回だけ』
63mukimi@hatena 2018/07/31 21:23
この記事はクラスに対する批判でしかないような?オブジェクト指向の肝はinterfaceだと思うんだけど。
64turanukimaru@hatena 2018/07/31 21:34
OOPの筋の悪さはもう十分に分かったので、大規模システムを関数型言語的に分析・設計する具体的な手順を誰か教えて欲しい…部品が関数になるのはわかるんだけどビジネスロジックをどうやって関数にすればいいのか。
65ukayare@hatena 2018/07/31 21:40
microserviceな設計ならそれでよかろうけど、大規模システムでそれやると地獄にしかならないような
66surume000@hatena 2018/07/31 21:55
まあ、ドメインによるわな。サーバ的な考えてみたらそもそもほとんど意味わからん。せっまいドメインを全てだと思っているのでは?
67hamlet-r@hatena 2018/07/31 21:56
OOA(分析)やOOD(設計)を抜きにして、OOPだけを語ってもね。対象となる世界への認識やモデリングを抜きにプログラムとか無意味だよ。関数型はモデリングの面で難解という印象しかない。何かいい教科書ないかな?
68unyaa@hatena 2018/07/31 22:01
委譲とコンポジション(転送)の違いが分からない。 ゴゴゴ /引っかかる箇所そこじゃ無いんだろうなぁ
69NetPenguin@hatena 2018/07/31 22:01
多態性や継承に依存したテクニックが全盛だった時代から、言語の表現力がさらにあがったことで違う解決方法を取れる、あえて多態性などを利用する必要がなくなってきた過渡期にいるのかもと思った。
70yasu-log@hatena 2018/07/31 22:12
ECMAScript陣営がclassのプライベートをprivate修飾子ではなく#にすると狂って議論してる間に、世の中は関数型となりclassが使われなくなるというのは、Blue-rayとHD DVDが競い合ってる間にHDDレコーダーが主流になったことのDéjàvu
71cl-gaku@hatena 2018/07/31 22:17
“リスコフの置換原則が守られないのは、歴史が明らかにしています。”
72coppieee@hatena 2018/07/31 22:32
そりゃJSはクラス以外にモジュール化する機能があるんだしクラスいらねぇよなぁってなる
73fa11enprince@hatena 2018/07/31 22:33
Game Programming Patternsはそんな過度な主張じゃなかった気がするので読み直してみよう。メンバ関数でなく非メンバ関数を推奨するのはADLの問題とか部分特殊化の問題とかC++ 特有の事情も少しあった気がする。他にもあるが。
74ymoage@hatena 2018/07/31 23:12
理解出来るまで読んでみよう。
75airj12@hatena 2018/07/31 23:13
プログラミングとしての継承はオーバーライドの副作用に苦しむから好きじゃないんだけど、設計(モデリング?)としては整理しやすく伝わり易いから好き
76whisper-monkey@hatena 2018/07/31 23:18
1段階目までの継承は終えるが2段階目で面倒になり3段階目で大体投げる。そして闇
77scorelessdraw@hatena 2018/07/31 23:26
分析と設計と実装をさも同じように扱ってしまったのがそもそもの混乱だったと思う、まぁ、10年ぐらい前の知識ですが。
78h1t0cH1@hatena 2018/07/31 23:34
悩ましい
79joe-re@hatena 2018/07/31 23:42
記事にも言及があるけど、特にview層で継承使っているコードに納得できるもの見たことないなー
80khtno73@hatena 2018/07/31 23:48
“ライブラリなどのよく練られたAPIの一回目の継承は規約として強烈なのですが、それが多段に継承されると protected が乱用され閉鎖原則が破綻しがちで、経験上この先は最悪なコードしか見ません。”あー。
81tasukenosuke@hatena 2018/07/31 23:49
関数指向ってオブジェクト指向の代替たりうるんけ?
82rryu@hatena 2018/08/01 00:13
抽象クラスを具象化する以上の継承をするとだいたい無理やり感が出て闇が生じる。
83tettekete37564@hatena 2018/08/01 00:29
OO dis の関数志向記事読むたびに思うんだけど、根本的に OO を理解しているのか不安になる。現実の世界では産業革命以前の大昔から OO で分業してるんよ。適切な分業とプロトコル設計できてなきゃクソになるのは変わらん
84daibutsuda@hatena 2018/08/01 01:19
とりあえず何でも継承していまい気がつけば5重6重当たり前のコードを見たことがあるが、真剣に殺意がわいた。
85neuecc@hatena 2018/08/01 02:49
オプションの例は別にそのままでいいんじゃない。コンストラクタに詰めるかプロパティに詰めるかを書き味とどの程度の変更可否で決めるかでしょふ。
86ntaoo@hatena 2018/08/01 04:13
オブジェクト指向でなくJava文化の呪い。OOPの本質はメッセージングと遅延結合で、必要に応じてそれを命令型でも関数型でも構成したら良い。クラスとミックスインとリフレクションと高階関数は非常に有用。
87lichten@hatena 2018/08/01 05:11
全く同意なんだけど、25年ぐらいオブジェクト指向やってきて負債しか作ってないのに反省することのない連中が変われるかっていうとねえ。若い連中は「Railsはオブジェクト指向」ぐらいの認識で特に呪われてないし
88sgo2@hatena 2018/08/01 05:16
OOPの利点はUMLに代表される様にモデル化が容易くドキュメント様式が規格化できる点にあるけど、UMLはコードに比べて表現力が劣る(各図で関数が描けないなど)が欠点。
89Nkzn@hatena 2018/08/01 05:30
同意だなあ。ジャバでもライブラリからの1回目の継承くらいしか継承は使わないようにしてるし。
90northlight@hatena 2018/08/01 06:23
DDDとかもそうだが、頭良い人が提唱する概念ってほとんどワークしない。ドメインがなんとか、オブジェクトがなんとか、ってお題目はいいんだけど、具体的なシステムで破綻のない実装してから言って欲しい。
91hihi01@hatena 2018/08/01 06:29
クラス、つまりは階級社会はいらない。それぞれの役割(ファンクション)を存分に発揮できる自由社会でありたいと。
92t-murachi@hatena 2018/08/01 08:36
概ね同意できる。これに批判してOOP (つかクラス指向) 擁護するブ※の趣旨の大半が「大規模開発ならワンチャンある」なの、闇深すぎだと思うよ(´・ω・`)
93tossy_yukky@hatena 2018/08/01 08:52
こういうエッジ(というほどでもないのかもしれないけど)な話為になる
94cuttoff19@hatena 2018/08/01 09:16
うおおお全然ついていけん
95ombran@hatena 2018/08/01 09:33
わかる。ただ、こういうのが分かる人を集めるのが何よりも大変
96wdr_s@hatena 2018/08/01 09:47
“もっといろんな言語の立場を書きたかったけど、JSの立場により過ぎた気します。”
97igrep@hatena 2018/08/01 10:08
関数指向ってなんですか... それはさておき、持論を加えると関数型プログラミングは局所的なプログラミングの方針、OOはモジュールの分け方の方針って割り切って使うとすっとすると思うよ(OOを大分狭く捉えてます)
98Nfm4yxnW8@hatena 2018/08/01 10:30
オブジェクト指向なんてものは実在せず、各々の心の中に異なった形で存在するファンタジーというのがよく分かるブコメ欄。
99cliffs@hatena 2018/08/01 11:10
staticおじさん、OOPおじさん、関数型おじさん、果てはチューリングマシンおじさんかな
100Horiuchi_H@hatena 2018/08/01 12:31
クラスはできるだけ使うな、というのは同意。あとは、ミュータブルなデータもなるべく減らしたい。
101gnety@hatena 2018/08/01 12:38
クラス指向のほうが圧倒的にわかりやすくプログラムを構成できるよ。第一級関数もあったほうがいいけど
102yarumato@hatena 2018/08/01 12:39
“本「Game Programming Patterns」が最高。ゲームを題材にして、ステートフルの扱いかたを語る。関数型や動的型付けならこうだからこれ不要と切り捨てるバランスが良い。とくに継承批判とシングルトン批判が強烈”
103kikiki-kiki@hatena 2018/08/01 14:32
アト=デ=ヨーム。OOPはAS3で学んだタイプのフレンズ。
104makinoshi@hatena 2018/08/01 15:01
いいね。Clojure書いていると状態が必要になる状況ってめちゃくちゃ少ないと気づくし、たまに他の言語書くと怖くて仕方ない。ES6ならconstな変数に無名関数即時実効で束縛するのが自然。
105TAKAMARU@hatena 2018/08/01 15:29
「オブジェクト指向」を「A列車で行こう」に聞き間違えるジャズファンが居るかどうか、調べておくこと。
106luccafort@hatena 2018/08/01 16:14
間違っているわけではないように感じるんだけどとはいえすんなりとそうですね!とも言い難いのはJSによりすぎている内容だからなのだろうか?JS前提なら割とすんなり受け入れられる。
107akabekobeko@hatena 2018/08/01 19:43
クラス ベースの言語経験が長いのだけど最近の JavaScript や Swift などに触発されて関数を積極的に使うようになった。状態依存を避ける設計の養成ギプスとしてよいと感じている。
108a-kuma3@hatena 2018/08/01 21:33
こじらせてる。とりあえず、この方がOOだと思っている何かの呪いにかかっているのは分かった。夢枕獏の陰陽師でも読んでみるのをお勧めする
109hachibeechan@hatena 2018/08/02 13:49
関数型試行してからフロントエンド書いてるとこういう思想になるよね。というかGoFが本書いた時代から「継承より委譲」は延々と言われ続けてるのに人はどうして継承スパゲッティを作ってしまうのだろう…
110masakitk@hatena 2018/08/11 22:23
継承、イミュータブルについては同意。validatorの例での主張がわからない。スコープ(モジュール)?分割のためにクラスを使うのは良くない、別の方法があるということかなぁ。
コメント内容の著作権は、投稿者に帰属します。
削除依頼、不適切コメントのご連絡はこちらにお願いいたします。
2018-08-11 02:57:01:1533923821:1534636936
comments powered by Disqus
※メールアドレスは公開されません。
人気の反応
0