Naofumi Kagami - 🇵🇸 lives matter (@naofumi) header
Naofumi Kagami - 🇵🇸 lives matter (@naofumi) profile picture

Aspiring Rails "Frontend" Engineer and Hotwire evangelist フロントエンド Rails エンジニア を目指しています!

Kawasaki, Japan
Joined January 2008
Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)Photo by Naofumi Kagami - 🇵🇸 lives matter (@naofumi)
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.
3
1
36
56,878
OOPのメソッド呼び出しで`Book.ship`ってやった時に、「主語がBookで動詞がshipはありえない!」って言っている人が多いけど、それを言ったら`Book.save`とか`Book.update`もおかしくなってしまう。 Bookは主語ではなく、ただのreceiverと呼ばれる。別に主語でも目的語でもどっちでも良いはず。 「主語がBookで動詞がshipはありえない!」って主張している人は、serviceやuse case中心に設計していて、あまりドメインモデルと作らないのかなぁって感じてしまう。 Martin Fowlerが言うところのドメイン貧血症的なやつを書いている人たちかも。
94
サカモト氏の`Book.ship`は117回リポストされて13万回表示されているっぽいけど、これをバズるパターンの一つ。 正しいポストよりも間違っているポストの方が伸びやすい。引用した時に自分の知識をひけらかしやすいから。これをわざと使っている強者もいるらしい。
1
1
8
685
自分も面白がってこのポストの引用を眺めているけど、残念ながら自分の意見に近い人をあまり見かけない。そこそこXで見かける人も含めて。引用している人が間違っているのか、私が間違っているのかになるけど、どっちだかわからない。 でもサカモト氏には感謝しかない。とても楽しい議論だ。
1
125
あとBookは自らをshipするのではなく、される側だからBook.shipはおかしいという意見については、これは英語の問題だと思う。 日本は語尾変化だけで使役にできるから"Book.出荷させる(address)"って書けば済む。英語も"Book.beshipped(address)"はできるけど自然じゃない。なんで妥協して"ship"に使役の意味を込めるのはありだと思うし、自分もそうする。
97
OOPや継承はいらないぜ!っていう人はフロントエンドやJavaScriptを書いている人が多い気がする。 そしてWeb FEはあくまでもDOMの上に成り立っていて、DOMはC++の継承を使って実装されている。 OOPや継承は不要だと感じるのは、土台でそれを使っているからかもしれない。
169
Naofumi Kagami - 🇵🇸 lives matter retweeted
Kaigi on Rails 2026の基調講演の動画を先行して公開しました!DHHとMatzの講演をぜひご覧ください。その他の発表も準備ができ次第公開します。 #kaigionrails youtube.com/playlist?list=PL…
43
1
93
5,162
あまりにも面白いので3回目の引用になってしまうけど、引用欄を見ているとかなり固定観念的な批判が多い。サカモト氏の意図はわからないが、私なりに `Book.ship` でも全然おかしくないケースを深掘りしてみたい。
継承は人類には難しすぎる。 例えば、書籍を表す Book クラスに ship(address) という配送メソッドを定義したとする。 その後、電子書籍を扱うことになり、EBook を継承で実装するとどうなるか。 電子書籍には物理的な配送先なんて存在しないのに、ship(address) を継承してしまう。 そもそも書籍の種類と配送方法は別の関心事。一回共通処理だと思って、クラスを設計をFixすると、後でいくらでも例外が出てめちゃくちゃなコードになる。 継承は俺には扱えない。
1
16
2,790
継承はOOPだけのものだと思われがちだけど、TypeScriptにも`extends`があり、その意味では立派な継承。OOPの継承も型の継承も誤用(乱用)してしまうとおかしなことになる。 何が違うかというと、OOPでは継承を一番最初に教えるけど、Typescriptのextendsはそうではないことぐらいじゃないか?
1
273
という感じで個人的な意見をダラダラと書いたけど、「`Book.ship`は絶対におかしいぜ!」とか「OOPはやばいぜ!」って一概に言えるほどには世の中は単純ではないことを伝えたかった。 大事なことは、継承とコンポジションの違いを理解し、それぞれの強み弱みを知ることじゃないかと思う。私の理解だと継承というのは単純に親クラスの全てのデータとメソッドを共有すること。それに対してコンポジションはより細かい粒度で共有するデータをメソッドを選択すること。 それと`ship`をどこに定義するべきかについては、DDD的に凝集を考えるか、Serviceを使うか、state machineにするかなどで色々変わるので、単純にビジネス上の意味論で考えるのはあまり価値がないと私は思う。
1
2
303
例えばMartin Fowlerぐらいのレベルになってくると、どんなにantipatternっぽいコードであってもそれが役に立つケースを思い出せると思うので、Book.shipだけを見て短絡的に判断しないのがたぶん正しいし、自分もその境地を目指したい。 ただし歳をとってくるとパターン認識に頼りがちなので危ない
4
267
> 継承という選択肢があることで誤用が生じるという話 これはその通りだとは思うし、継承がひどい使われ方をしているケースは確かに見かける。問題になった具体的なケースはJavaの標準ライブラリーにも確かあったはず。 でもRubyだと結構良い使われ方をしている。特にmixinやconcern的なやつ。
160
引用が面白い。シンプルに揶揄することもできるけど、この例に限って言えばOOPだけでなくモデリングの問題なので、そこまで突っ込むとさらに面白い。 私の見解だと、出荷業務は必ず伝票の授受が発生する。だからShipmentもしくはShippingInvoice等のcreateになる。
継承は人類には難しすぎる。 例えば、書籍を表す Book クラスに ship(address) という配送メソッドを定義したとする。 その後、電子書籍を扱うことになり、EBook を継承で実装するとどうなるか。 電子書籍には物理的な配送先なんて存在しないのに、ship(address) を継承してしまう。 そもそも書籍の種類と配送方法は別の関心事。一回共通処理だと思って、クラスを設計をFixすると、後でいくらでも例外が出てめちゃくちゃなコードになる。 継承は俺には扱えない。
1
2
2
11
2,114
それでBook.shipを擁護する意見としては、Shipmentのcreateをダイレクトにcontrollerやserviceに書いても良いけど、でもBookをstate machineにしているならBook.shipみたいなステート遷移のメソッドを作って、出荷処理とBookのステート遷移(shippedにする)をまとめるのも良さそう。 親クラスの話は別だけど、Bookにshipというメソッドがあっちゃいけないとは断言できないのが私の見解。
1
4
328