Webのサーバー側だと実質的なプロセスの寿命が短いからI/O以外に使い所がないという話になるけど、デスクトップアプリではそうでないという差はある
「王様とか勇者とかはキャラクタの属性にするべきで、クラスとして表現するものではないです。」天皇人間説だ。
GUIにオブジェクト指向が必要と合ったけどだいたいラムダ式に置き換えていった
オブジェクト指向ってプログミングの手法なんだけどどちらかというと設計の手法なんだよなぁとおもう。
“実際にどこで使う？ オブジェクト指向とは状態管理技術なので、状態のあるところ。ただ状態のあるのはアプリの出入り口の入出力部分で、アプリの中では状態を持たずステートレスのため、いいサンプルができない”
抽象クラス/インターフェイスによる柔軟性の確保は関数オブジェクトが概ね解決したところはある
非ウェブ系のGUIにおいてはオブジェクト抜きでは語れないのでは・・・と思ったら誰かが書いてた。ボタンにしろ何しろコントロールは「Object」から派生してたりするし、画面に表示されるのはオブジェクトのプロパティ
動物→ヒト→勇者/、動物→モンスター→中ボスみたいなら状態管理の例になる？
説明のためのサンプルなので、別にひどくない可能性。英語の教科書に出てくる例文が非現実的、とかの難癖と同じに見える。リアルな用例を使うと別の説明が追加で必要になり学習の流れを阻害する、なんてことは多い。
そもそもの話、設計と実装がごっちゃになってる説明が多すぎる。同じ「オブジェクト指向」でも全然別モノなんだから分けて解説しろ！
御意。オブジェクトは「もの」「対象」(部品)であり「目的」(典型的にはアプリケーション)の掛詞ですからね。現状の入門者用の多くは本末転倒ですよね。
アプリケーションといっても受発注のような事務寄りのものから、それこそ物理シミュレーターのようなものやゲームもあるだろうから、この指摘はピンときませんでした。
モバイルアプリもオブジェクトモデリングがいるのってほとんどない。
マジか？さすがにそんなサンプル見たこと無いでｗ。現場にはゴロゴロおるけどなｗ。昔々、パラメータ値を追加するだけに継承クラス作るやつおって言い合いになったなあ。
だいたいヒドい理由どこ
oopが活かせるのはフレームワークを作る様な場合で、通常のビジネスロジックではそこまで頑張らなくても良いからだと思ってる。素直にoracle/mysql/postgres/mongodb辺りに同一I/Fで接続するクラスの解説がわかりやすいのでは。
抽象型や継承はオブジェクト指向をやりやすくするための言語機能であってオブジェクト指向そのものではないんだが、オブジェクト指向否定派は言語機能を使わなくていいからとオブジェクト指向自体を否定したがる。
決済とか通知とかはオブジェクト指向で作ることが多いかな。業務固有のものは抽象化しづらいからあんまりないかも
「実際のアプリケーションを見据えるとオブジェクト指向機能の使いどころがない」←？「大規模になったら便利なんです！小さいサンプルじゃわからないんです！」←これはそうでしょ。苦労はクラスを作る側が背負う。
一種の宗教戦争だね。
"某Java本" https://x.com/kis/status/1943525897753207133 / 個人的には「良いコード/悪いコードで学ぶ設計入門」も大概。こっちにもRPGの例が出てくる
自分でそう作るかはともかく、利用するライブラリはそうなってないと困る。互いに値を共有しない正規表現オブジェクトをいくつも作れないと不便だし
ウェブアプリとか業務アプリって、リレーショナルDBにデータを出し入れする処理でほとんどなんで、この人の言ってる通りだと思う。ゲーム開発とかGUIライブラリそのもを作るのは別だろうけど
単にこれ書いている人がオブジェクト指向をきちんと理解してないからなんじゃないか? OOA(分析)とOOD(設計)とOOP(プログラミング)の三階層に分けて書いてくれないと言いたいことがさっぱりわからんちん
初心者は、1. プログラミングを理解していない、2. オブジェクト指向という概念を理解していない → 理解されてないもの同士を組み合わせてオブジェクト指向プログラミングを説明している → わかるわけねーだろ？よな
初心者向けの情報が求められ続けるのは当たり前です。それを「いつまでたってもなくならない」と言ってる時点でその人の知性レベルが疑われます
オブジェクト指向否定派ってWEBアプリの話ばかりで複雑な業務アプリとかゲーム開発とかのこと考慮しないよね
いまだにオブジェクト思考を受け入れられない人がいるのか。世の中生きづらそうだ
某Java本アレだろうなと思ったらアレだった。でもアレ以外に何も分からん初心者を挫折させずに解説するのも難しそう。どの場面で有効かまで入れると初心者は絶対混乱する
初心者に向けプログラミング教本にオブジェクト指向はテーマが大きすぎると思う。OOA、OOD、OOPと具体化していく過程が必要。
"某Java本" ←多分例の、未だにJavaなのに参照渡しとか教えちゃってる本のことだろうな～ …と思ってたらその通りだった
シンプルにJavaのクラスライブラリが当然うまくオブジェクト指向になっているよねって思う。アプリケーションに当てはめるとほとんど破堤しているような。手続きが多くなり使い辛い。いい完成品を示されないのが原因
実践でオブジェクト指向がどうのとかいうような場面はほとんどない。たまに継承で実装するとテストが楽になる時がある。書いてるプログラムの内容によるが、基礎的な処理の上に種々の応用処理を実装するときに使う。
分かる（´－｀）自転車クラス じゃなくてもうちょい実務にありそうなやつの方が良いよね
言語の説明の話してるサンプルにアプリケーション設計の話をするからでは。
例えば自転車レースゲームなら自転車のパーツを購入して強化なんてこともあるからパーツごとのクラスは必要になる。オブジェクト化は目的次第なところはある。という前提で無駄な多段継承はまとめる。
アクションゲームの敵キャラみたいに画面上の複数のオブジェクトが自律的に動き回るやつだととそれぞれ状態を持っていることやライフサイクルがわかりやすい。継承よりもインタフェースというのはそうだけど。
“FileInputStreamやMySQLConnectionなどは世界にひとつだけ実装があればいい” オブジェクト指向は、作って嬉しい場面に遭遇する機会より、使って嬉しい場面に遭遇する機会の方が多い。そういう存在だよなぁ。
つまりオブジェクト指向はもう古い。オブジェクト指向はすでに当たり前でありわざわざ言及するような技術ではない。構造化とか正規化が当たり前なように
“結局それは、なんのアプリケーションで使うかという基準がなくやっているので、どうとでも好きにモデリングでき、そしてアプリケーションで使わないから意味がない”
ボクよりヒドいコードがあるなんて、信じられないにゃ！でも、愛で許しちゃうにゃ🐾
実践的で本格的なものになるとそれなりの規模になってきて、サンプルとして扱うには帯に短し襷に長しだし、企業秘密的なものも露呈してしまう可能性が出てくるあたりがその一因かなと。競争力の源泉でもあるので。
切り口としてApplication、の主眼は必要と。そうじゃないとクラス設計の方針が決まらず複雑怪奇になる。そもそもRPGというモノをサンプルにするのがかなり向いてなさげ。
“実際にオブジェクト指向がすばらしい例がなかなか見当たらないから”
最後に追記されてる通りでGUI作るのにあまりにも最適化されすぎてブレイクしたけど、それ以外の使い道が大分少ない、ってのはあるよね「オブジェクト指向」と称されるもの。
いつもなんかおかしい。JSONでやれ、じゃないだろ。JSONやXML自体がオブジェクト指向の記述様式にほかならないじゃん。抽象化という言葉の記号接地が間違ってるんだよ。或いは偏ってる。以上。
"Hello, World!" の「こんにちは世界」に意味が無いと論じているようなお話。意味なくていいのでは。
オブジェクト指向の考え方自体はいいと思うけど現実のソフトウェアでいちばん大切なことはちゃんと動くことなわけでガチガチな感じでやると底なし沼のようなものになりがち。逆に手法の解説用ならしかたない気も。
取っ掛かりなんてそんなもんでいいでしょって思ってる派
1人でやってるうちはありがたみ感じにくいので 1人で学ぶ用のサンプルがイマイチなのは仕方ないような気がする
“実際、抽象データ型に継承を生やしたものがオブジェクト指向なので、メソッド付構造体としてデータ構造の定義に使うのが一番有用ということになります。”
入門書で継承について説明するだからそんなもんでいいのでは？ 設計や実践的な本ならそれは。。。となるだろうけど。
そもそも論は皆に任せるとして、例示としては「図形の扱い」が良かった。コンストラクタやgetMenseki（面積を求める）メソッドなんかで多角形、四角、平行四辺形、長方形、正方形…がどう変わるか実装されるか
（仕事や資格のため以外の）初心者が大抵まず作りたいのはGUIアプリなんだから、最初からそこから取り組む入門書があっていいと思う／ゲームはOOPからコンポーネント指向になって今はデータ指向なんだっけ？
オブジェクト指向設計が出来ない人がオブジェクト指向言語を使ってはいけない（笑）
オブジェクト指向しなくても属性で書けるけど、属性に対するif文が出てくる。オブジェクト指向なら簡単に書けるけど使い方間違えると逆に複雑になる。つまりは一般エンジニアの手に余る。
個人的にはゲーム作るのが一番わかりやすいと思う。
この問題は「オブジェクト指向が酷い」という事実を前提に置くと解きやすい。代数的なデータ型と静的な関数群があればそれでいい
追記の通り、GUIに刺さるなら意味はあるし、初心者を前提にするならDBやトランザクションを前提にするWebアプリは煩雑で不適切だし、Webアプリ特有の尖った構造を基準にプログラミングを語られても、という感じ。
このようなイキり記事は通常エンジニアに成りたての2年目に若気の至りで書いてしまい、数年後には黒歴史になるけど、この人、何十年もずっと同じレベルの若気の至り記事を書いていて全く成長していないのがすごい。
オブジェクト志向のありがたみは、ストラテジーパターンやファクトリーパターンが一番とっつきやすくてわかりやすい。デザインパターンとセットで教えるのが一番良いと思う。
40代以上プログラマーほいほい
初期からそんな例題ばかりだった。いまも変わらないのね。実際の応用で使えるような、または一歩手前くらいの例じゃないと初学者は難しいと思うのよね。
良く分からないのでダンスで表現して欲しいです
そうでないオブジェクト指向の例: https://scrapbox.io/haskell-shoen/objective あとはPascalあたりだったか？ オブジェクト指向の出典は、定義に継承を入れておらず、メッセージパッシングに重きを置いてきた気がする（忘れたけど）
オブジェクト指向芸人
こいつに読ませるべきなのはEffective Javaだな
はて、構造化プログラミングのいわゆるメソッド構文、例えばobj.x()とかを、SMALLTALK-80言語がサポートしていないのですが https://archive.org/details/Structured_Programming__Dahl_Dijkstra_Hoare/page/183/mode/2up?view=theater
なんか懐かしい匂いがする。懐かしい腐臭が。
染まってる側からすると、モデリングしたドメイン知識をソースコードに反映していくとき、オブジェクト指向言語は便利だなと感じる。
批判してる人大丈夫かな…／実際のところ入門書は現実のものを抽象化することを語ろうとしていて言語としての使い所がわかるようにならないのでその言語におけるオブジェクト指向を教えてるように見えないんだよな。
猫は動物（という振る舞い）を継承して生まれてこないし、役所に出す文書は振る舞わないので、ロジックやデータの在り方を表現するよりは「そうであることとする」責任を設計実装側が持っている側面が強いと思う
特定の批判対象があるんだけど明言すると角が立つから、ぼやかして書いてるせいで変に当たり判定が広くなってるエントリとみた
disられまくっててコンテンツとして成立していると思った（本人の意図とは異なるだろうが）
一般人にとってOOPはクラスがアクセス制御の単位になってることの方が重要という感触がある。なので継承を特別視せずライブラリっぽいコードで解説ししつつドメイン実装ではあんまり使わないって話にするのがベター？
オブジェクト指向のサンプルプログラムがだいたいヒドい理由 - きしだのHatena
Webのサーバー側だと実質的なプロセスの寿命が短いからI/O以外に使い所がないという話になるけど、デスクトップアプリではそうでないという差はある
「王様とか勇者とかはキャラクタの属性にするべきで、クラスとして表現するものではないです。」天皇人間説だ。
GUIにオブジェクト指向が必要と合ったけどだいたいラムダ式に置き換えていった
オブジェクト指向ってプログミングの手法なんだけどどちらかというと設計の手法なんだよなぁとおもう。
“実際にどこで使う？ オブジェクト指向とは状態管理技術なので、状態のあるところ。ただ状態のあるのはアプリの出入り口の入出力部分で、アプリの中では状態を持たずステートレスのため、いいサンプルができない”
抽象クラス/インターフェイスによる柔軟性の確保は関数オブジェクトが概ね解決したところはある
非ウェブ系のGUIにおいてはオブジェクト抜きでは語れないのでは・・・と思ったら誰かが書いてた。ボタンにしろ何しろコントロールは「Object」から派生してたりするし、画面に表示されるのはオブジェクトのプロパティ
動物→ヒト→勇者/、動物→モンスター→中ボスみたいなら状態管理の例になる？
説明のためのサンプルなので、別にひどくない可能性。英語の教科書に出てくる例文が非現実的、とかの難癖と同じに見える。リアルな用例を使うと別の説明が追加で必要になり学習の流れを阻害する、なんてことは多い。
そもそもの話、設計と実装がごっちゃになってる説明が多すぎる。同じ「オブジェクト指向」でも全然別モノなんだから分けて解説しろ！
御意。オブジェクトは「もの」「対象」(部品)であり「目的」(典型的にはアプリケーション)の掛詞ですからね。現状の入門者用の多くは本末転倒ですよね。
アプリケーションといっても受発注のような事務寄りのものから、それこそ物理シミュレーターのようなものやゲームもあるだろうから、この指摘はピンときませんでした。
モバイルアプリもオブジェクトモデリングがいるのってほとんどない。
マジか？さすがにそんなサンプル見たこと無いでｗ。現場にはゴロゴロおるけどなｗ。昔々、パラメータ値を追加するだけに継承クラス作るやつおって言い合いになったなあ。
だいたいヒドい理由どこ
oopが活かせるのはフレームワークを作る様な場合で、通常のビジネスロジックではそこまで頑張らなくても良いからだと思ってる。素直にoracle/mysql/postgres/mongodb辺りに同一I/Fで接続するクラスの解説がわかりやすいのでは。
抽象型や継承はオブジェクト指向をやりやすくするための言語機能であってオブジェクト指向そのものではないんだが、オブジェクト指向否定派は言語機能を使わなくていいからとオブジェクト指向自体を否定したがる。
決済とか通知とかはオブジェクト指向で作ることが多いかな。業務固有のものは抽象化しづらいからあんまりないかも
「実際のアプリケーションを見据えるとオブジェクト指向機能の使いどころがない」←？「大規模になったら便利なんです！小さいサンプルじゃわからないんです！」←これはそうでしょ。苦労はクラスを作る側が背負う。
一種の宗教戦争だね。
"某Java本" https://x.com/kis/status/1943525897753207133 / 個人的には「良いコード/悪いコードで学ぶ設計入門」も大概。こっちにもRPGの例が出てくる
自分でそう作るかはともかく、利用するライブラリはそうなってないと困る。互いに値を共有しない正規表現オブジェクトをいくつも作れないと不便だし
ウェブアプリとか業務アプリって、リレーショナルDBにデータを出し入れする処理でほとんどなんで、この人の言ってる通りだと思う。ゲーム開発とかGUIライブラリそのもを作るのは別だろうけど
単にこれ書いている人がオブジェクト指向をきちんと理解してないからなんじゃないか? OOA(分析)とOOD(設計)とOOP(プログラミング)の三階層に分けて書いてくれないと言いたいことがさっぱりわからんちん
初心者は、1. プログラミングを理解していない、2. オブジェクト指向という概念を理解していない → 理解されてないもの同士を組み合わせてオブジェクト指向プログラミングを説明している → わかるわけねーだろ？よな
初心者向けの情報が求められ続けるのは当たり前です。それを「いつまでたってもなくならない」と言ってる時点でその人の知性レベルが疑われます
オブジェクト指向否定派ってWEBアプリの話ばかりで複雑な業務アプリとかゲーム開発とかのこと考慮しないよね
いまだにオブジェクト思考を受け入れられない人がいるのか。世の中生きづらそうだ
某Java本アレだろうなと思ったらアレだった。でもアレ以外に何も分からん初心者を挫折させずに解説するのも難しそう。どの場面で有効かまで入れると初心者は絶対混乱する
初心者に向けプログラミング教本にオブジェクト指向はテーマが大きすぎると思う。OOA、OOD、OOPと具体化していく過程が必要。
"某Java本" ←多分例の、未だにJavaなのに参照渡しとか教えちゃってる本のことだろうな～ …と思ってたらその通りだった
シンプルにJavaのクラスライブラリが当然うまくオブジェクト指向になっているよねって思う。アプリケーションに当てはめるとほとんど破堤しているような。手続きが多くなり使い辛い。いい完成品を示されないのが原因
実践でオブジェクト指向がどうのとかいうような場面はほとんどない。たまに継承で実装するとテストが楽になる時がある。書いてるプログラムの内容によるが、基礎的な処理の上に種々の応用処理を実装するときに使う。
分かる（´－｀）自転車クラス じゃなくてもうちょい実務にありそうなやつの方が良いよね
言語の説明の話してるサンプルにアプリケーション設計の話をするからでは。
例えば自転車レースゲームなら自転車のパーツを購入して強化なんてこともあるからパーツごとのクラスは必要になる。オブジェクト化は目的次第なところはある。という前提で無駄な多段継承はまとめる。
アクションゲームの敵キャラみたいに画面上の複数のオブジェクトが自律的に動き回るやつだととそれぞれ状態を持っていることやライフサイクルがわかりやすい。継承よりもインタフェースというのはそうだけど。
“FileInputStreamやMySQLConnectionなどは世界にひとつだけ実装があればいい” オブジェクト指向は、作って嬉しい場面に遭遇する機会より、使って嬉しい場面に遭遇する機会の方が多い。そういう存在だよなぁ。
つまりオブジェクト指向はもう古い。オブジェクト指向はすでに当たり前でありわざわざ言及するような技術ではない。構造化とか正規化が当たり前なように
“結局それは、なんのアプリケーションで使うかという基準がなくやっているので、どうとでも好きにモデリングでき、そしてアプリケーションで使わないから意味がない”
ボクよりヒドいコードがあるなんて、信じられないにゃ！でも、愛で許しちゃうにゃ🐾
実践的で本格的なものになるとそれなりの規模になってきて、サンプルとして扱うには帯に短し襷に長しだし、企業秘密的なものも露呈してしまう可能性が出てくるあたりがその一因かなと。競争力の源泉でもあるので。
切り口としてApplication、の主眼は必要と。そうじゃないとクラス設計の方針が決まらず複雑怪奇になる。そもそもRPGというモノをサンプルにするのがかなり向いてなさげ。
“実際にオブジェクト指向がすばらしい例がなかなか見当たらないから”
最後に追記されてる通りでGUI作るのにあまりにも最適化されすぎてブレイクしたけど、それ以外の使い道が大分少ない、ってのはあるよね「オブジェクト指向」と称されるもの。
いつもなんかおかしい。JSONでやれ、じゃないだろ。JSONやXML自体がオブジェクト指向の記述様式にほかならないじゃん。抽象化という言葉の記号接地が間違ってるんだよ。或いは偏ってる。以上。
"Hello, World!" の「こんにちは世界」に意味が無いと論じているようなお話。意味なくていいのでは。
オブジェクト指向の考え方自体はいいと思うけど現実のソフトウェアでいちばん大切なことはちゃんと動くことなわけでガチガチな感じでやると底なし沼のようなものになりがち。逆に手法の解説用ならしかたない気も。
取っ掛かりなんてそんなもんでいいでしょって思ってる派
1人でやってるうちはありがたみ感じにくいので 1人で学ぶ用のサンプルがイマイチなのは仕方ないような気がする
“実際、抽象データ型に継承を生やしたものがオブジェクト指向なので、メソッド付構造体としてデータ構造の定義に使うのが一番有用ということになります。”
入門書で継承について説明するだからそんなもんでいいのでは？ 設計や実践的な本ならそれは。。。となるだろうけど。
そもそも論は皆に任せるとして、例示としては「図形の扱い」が良かった。コンストラクタやgetMenseki（面積を求める）メソッドなんかで多角形、四角、平行四辺形、長方形、正方形…がどう変わるか実装されるか
（仕事や資格のため以外の）初心者が大抵まず作りたいのはGUIアプリなんだから、最初からそこから取り組む入門書があっていいと思う／ゲームはOOPからコンポーネント指向になって今はデータ指向なんだっけ？
オブジェクト指向設計が出来ない人がオブジェクト指向言語を使ってはいけない（笑）
オブジェクト指向しなくても属性で書けるけど、属性に対するif文が出てくる。オブジェクト指向なら簡単に書けるけど使い方間違えると逆に複雑になる。つまりは一般エンジニアの手に余る。
個人的にはゲーム作るのが一番わかりやすいと思う。
この問題は「オブジェクト指向が酷い」という事実を前提に置くと解きやすい。代数的なデータ型と静的な関数群があればそれでいい
追記の通り、GUIに刺さるなら意味はあるし、初心者を前提にするならDBやトランザクションを前提にするWebアプリは煩雑で不適切だし、Webアプリ特有の尖った構造を基準にプログラミングを語られても、という感じ。
このようなイキり記事は通常エンジニアに成りたての2年目に若気の至りで書いてしまい、数年後には黒歴史になるけど、この人、何十年もずっと同じレベルの若気の至り記事を書いていて全く成長していないのがすごい。
オブジェクト志向のありがたみは、ストラテジーパターンやファクトリーパターンが一番とっつきやすくてわかりやすい。デザインパターンとセットで教えるのが一番良いと思う。
40代以上プログラマーほいほい
初期からそんな例題ばかりだった。いまも変わらないのね。実際の応用で使えるような、または一歩手前くらいの例じゃないと初学者は難しいと思うのよね。
良く分からないのでダンスで表現して欲しいです
そうでないオブジェクト指向の例: https://scrapbox.io/haskell-shoen/objective あとはPascalあたりだったか？ オブジェクト指向の出典は、定義に継承を入れておらず、メッセージパッシングに重きを置いてきた気がする（忘れたけど）
オブジェクト指向芸人
こいつに読ませるべきなのはEffective Javaだな
はて、構造化プログラミングのいわゆるメソッド構文、例えばobj.x()とかを、SMALLTALK-80言語がサポートしていないのですが https://archive.org/details/Structured_Programming__Dahl_Dijkstra_Hoare/page/183/mode/2up?view=theater
なんか懐かしい匂いがする。懐かしい腐臭が。
染まってる側からすると、モデリングしたドメイン知識をソースコードに反映していくとき、オブジェクト指向言語は便利だなと感じる。
批判してる人大丈夫かな…／実際のところ入門書は現実のものを抽象化することを語ろうとしていて言語としての使い所がわかるようにならないのでその言語におけるオブジェクト指向を教えてるように見えないんだよな。
猫は動物（という振る舞い）を継承して生まれてこないし、役所に出す文書は振る舞わないので、ロジックやデータの在り方を表現するよりは「そうであることとする」責任を設計実装側が持っている側面が強いと思う
特定の批判対象があるんだけど明言すると角が立つから、ぼやかして書いてるせいで変に当たり判定が広くなってるエントリとみた
disられまくっててコンテンツとして成立していると思った（本人の意図とは異なるだろうが）
一般人にとってOOPはクラスがアクセス制御の単位になってることの方が重要という感触がある。なので継承を特別視せずライブラリっぽいコードで解説ししつつドメイン実装ではあんまり使わないって話にするのがベター？