What’s kind of scary when posting Ruby/Rails content in English and having the honor of being followed, is that you WILL be followed by people who have opposing political views, and I do post political stuff here (I do display the Palestine flag).
I just hope that we can all parse out our differences and share what we both love. I know it’s not easy, and I definitely need to be more mature, but I hope it actually brings the world together. People say social media is an echo chamber and this is very true, but it can also work the other way too.
I think I’m kind of saying that, I hope that our love of Ruby/Rails will help bring us together for world peace.
OOPのメソッド呼び出しで`Book.ship`ってやった時に、「主語がBookで動詞がshipはありえない!」って言っている人が多いけど、それを言ったら`Book.save`とか`Book.update`もおかしくなってしまう。
Bookは主語ではなく、ただのreceiverと呼ばれる。別に主語でも目的語でもどっちでも良いはず。
「主語がBookで動詞がshipはありえない!」って主張している人は、serviceやuse case中心に設計していて、あまりドメインモデルと作らないのかなぁって感じてしまう。
Martin Fowlerが言うところのドメイン貧血症的なやつを書いている人たちかも。
サカモト氏の`Book.ship`は117回リポストされて13万回表示されているっぽいけど、これをバズるパターンの一つ。
正しいポストよりも間違っているポストの方が伸びやすい。引用した時に自分の知識をひけらかしやすいから。これをわざと使っている強者もいるらしい。
自分も面白がってこのポストの引用を眺めているけど、残念ながら自分の意見に近い人をあまり見かけない。そこそこXで見かける人も含めて。引用している人が間違っているのか、私が間違っているのかになるけど、どっちだかわからない。
でもサカモト氏には感謝しかない。とても楽しい議論だ。
OOPや継承はいらないぜ!っていう人はフロントエンドやJavaScriptを書いている人が多い気がする。
そしてWeb FEはあくまでもDOMの上に成り立っていて、DOMはC++の継承を使って実装されている。
OOPや継承は不要だと感じるのは、土台でそれを使っているからかもしれない。
Naofumi Kagami - 🇵🇸 lives matter retweeted
Kaigi on Rails 2026の基調講演の動画を先行して公開しました!DHHとMatzの講演をぜひご覧ください。その他の発表も準備ができ次第公開します。
#kaigionrails
youtube.com/playlist?list=PL…
あまりにも面白いので3回目の引用になってしまうけど、引用欄を見ているとかなり固定観念的な批判が多い。サカモト氏の意図はわからないが、私なりに `Book.ship` でも全然おかしくないケースを深掘りしてみたい。
継承はOOPだけのものだと思われがちだけど、TypeScriptにも`extends`があり、その意味では立派な継承。OOPの継承も型の継承も誤用(乱用)してしまうとおかしなことになる。
何が違うかというと、OOPでは継承を一番最初に教えるけど、Typescriptのextendsはそうではないことぐらいじゃないか?
という感じで個人的な意見をダラダラと書いたけど、「`Book.ship`は絶対におかしいぜ!」とか「OOPはやばいぜ!」って一概に言えるほどには世の中は単純ではないことを伝えたかった。
大事なことは、継承とコンポジションの違いを理解し、それぞれの強み弱みを知ることじゃないかと思う。私の理解だと継承というのは単純に親クラスの全てのデータとメソッドを共有すること。それに対してコンポジションはより細かい粒度で共有するデータをメソッドを選択すること。
それと`ship`をどこに定義するべきかについては、DDD的に凝集を考えるか、Serviceを使うか、state machineにするかなどで色々変わるので、単純にビジネス上の意味論で考えるのはあまり価値がないと私は思う。
例えばMartin Fowlerぐらいのレベルになってくると、どんなにantipatternっぽいコードであってもそれが役に立つケースを思い出せると思うので、Book.shipだけを見て短絡的に判断しないのがたぶん正しいし、自分もその境地を目指したい。
ただし歳をとってくるとパターン認識に頼りがちなので危ない
> 継承という選択肢があることで誤用が生じるという話
これはその通りだとは思うし、継承がひどい使われ方をしているケースは確かに見かける。問題になった具体的なケースはJavaの標準ライブラリーにも確かあったはず。
でもRubyだと結構良い使われ方をしている。特にmixinやconcern的なやつ。
引用が面白い。シンプルに揶揄することもできるけど、この例に限って言えばOOPだけでなくモデリングの問題なので、そこまで突っ込むとさらに面白い。
私の見解だと、出荷業務は必ず伝票の授受が発生する。だからShipmentもしくはShippingInvoice等のcreateになる。


