Webのサーバー側だと実質的なプロセスの寿命が短いからI/O以外に使い所がないという話になるけど、デスクトップアプリではそうでないという差はある
「王様とか勇者とかはキャラクタの属性にするべきで、クラスとして表現するものではないです。」天皇人間説だ。
GUIにオブジェクト指向が必要と合ったけどだいたいラムダ式に置き換えていった
オブジェクト指向ってプログミングの手法なんだけどどちらかというと設計の手法なんだよなぁとおもう。
“実際にどこで使う？ オブジェクト指向とは状態管理技術なので、状態のあるところ。ただ状態のあるのはアプリの出入り口の入出力部分で、アプリの中では状態を持たずステートレスのため、いいサンプルができない”
抽象クラス/インターフェイスによる柔軟性の確保は関数オブジェクトが概ね解決したところはある
非ウェブ系のGUIにおいてはオブジェクト抜きでは語れないのでは・・・と思ったら誰かが書いてた。ボタンにしろ何しろコントロールは「Object」から派生してたりするし、画面に表示されるのはオブジェクトのプロパティ
動物→ヒト→勇者/、動物→モンスター→中ボスみたいなら状態管理の例になる？
説明のためのサンプルなので、別にひどくない可能性。英語の教科書に出てくる例文が非現実的、とかの難癖と同じに見える。リアルな用例を使うと別の説明が追加で必要になり学習の流れを阻害する、なんてことは多い。
そもそもの話、設計と実装がごっちゃになってる説明が多すぎる。同じ「オブジェクト指向」でも全然別モノなんだから分けて解説しろ！
御意。オブジェクトは「もの」「対象」(部品)であり「目的」(典型的にはアプリケーション)の掛詞ですからね。現状の入門者用の多くは本末転倒ですよね。
アプリケーションといっても受発注のような事務寄りのものから、それこそ物理シミュレーターのようなものやゲームもあるだろうから、この指摘はピンときませんでした。
モバイルアプリもオブジェクトモデリングがいるのってほとんどない。
マジか？さすがにそんなサンプル見たこと無いでｗ。現場にはゴロゴロおるけどなｗ。昔々、パラメータ値を追加するだけに継承クラス作るやつおって言い合いになったなあ。
だいたいヒドい理由どこ
oopsが活かせるのはフレームワークを作る様な場合で、通常のビジネスロジックではそこまで頑張らなくても良いからだと思ってる。素直にoracle/mysql/postgres/mongodb辺りに同一I/Fで接続するクラスの解説がわかりやすいのでは。
抽象型や継承はオブジェクト指向をやりやすくするための言語機能であってオブジェクト指向そのものではないんだが、オブジェクト指向否定派は言語機能を使わなくていいからとオブジェクト指向自体を否定したがる。
決済とか通知とかはオブジェクト指向で作ることが多いかな。業務固有のものは抽象化しづらいからあんまりないかも
「実際のアプリケーションを見据えるとオブジェクト指向機能の使いどころがない」←？「大規模になったら便利なんです！小さいサンプルじゃわからないんです！」←これはそうでしょ。苦労はクラスを作る側が背負う。
一種の宗教戦争だね。
この筆者基礎知識がないのにいつも低俗な煽り記事を書きますね。「継承はだめだけどInputSteamの継承は便利」。モダンな言語は入出力ストリームもクラス継承なんて使わずに全部型クラスベース。Java屋さんは100年遅れてる
"某Java本" https://x.com/kis/status/1943525897753207133 / 個人的には「良いコード/悪いコードで学ぶ設計入門」も大概。こっちにもRPGの例が出てくる
自分でそう作るかはともかく、利用するライブラリはそうなってないと困る。互いに値を共有しない正規表現オブジェクトをいくつも作れないと不便だし
ウェブアプリとか業務アプリって、リレーショナルDBにデータを出し入れする処理でほとんどなんで、この人の言ってる通りだと思う。ゲーム開発とかGUIライブラリそのもを作るのは別だろうけど
単にこれ書いている人がオブジェクト指向をきちんと理解してないからなんじゃないか? OOA(分析)とOOD(設計)とOOP(プログラミング)の三階層に分けて書いてくれないと言いたいことがさっぱりわからんちん
初心者は、1. プログラミングを理解していない、2. オブジェクト指向という概念を理解していない → 理解されてないもの同士を組み合わせてオブジェクト指向プログラミングを説明している → わかるわけねーだろ？よな
初心者向けの情報が求められ続けるのは当たり前です。それを「いつまでたってもなくならない」と言ってる時点でその人の知性レベルが疑われます
オブジェクト指向否定派ってWEBアプリの話ばかりで複雑な業務アプリとかゲーム開発とかのこと考慮しないよね
いまだにオブジェクト思考を受け入れられない人がいるのか。世の中生きづらそうだ
某Java本アレだろうなと思ったらアレだった。でもアレ以外に何も分からん初心者を挫折させずに解説するのも難しそう。どの場面で有効かまで入れると初心者は絶対混乱する
初心者に向けプログラミング教本にオブジェクト指向はテーマが大きすぎると思う。OOA、OOD、OOPと具体化していく過程が必要。
"某Java本" ←多分例の、未だにJavaなのに参照渡しとか教えちゃってる本のことだろうな～ …と思ってたらその通りだった
シンプルにJavaのクラスライブラリが当然うまくオブジェクト指向になっているよねって思う。アプリケーションに当てはめるとほとんど破堤しているような。手続きが多くなり使い辛い。いい完成品を示されないのが原因
実践でオブジェクト指向がどうのとかいうような場面はほとんどない。たまに継承で実装するとテストが楽になる時がある。書いてるプログラムの内容によるが、基礎的な処理の上に種々の応用処理を実装するときに使う。
オブジェクト指向のサンプルプログラムがだいたいヒドい理由 - きしだのHatena
Webのサーバー側だと実質的なプロセスの寿命が短いからI/O以外に使い所がないという話になるけど、デスクトップアプリではそうでないという差はある
「王様とか勇者とかはキャラクタの属性にするべきで、クラスとして表現するものではないです。」天皇人間説だ。
GUIにオブジェクト指向が必要と合ったけどだいたいラムダ式に置き換えていった
オブジェクト指向ってプログミングの手法なんだけどどちらかというと設計の手法なんだよなぁとおもう。
“実際にどこで使う？ オブジェクト指向とは状態管理技術なので、状態のあるところ。ただ状態のあるのはアプリの出入り口の入出力部分で、アプリの中では状態を持たずステートレスのため、いいサンプルができない”
抽象クラス/インターフェイスによる柔軟性の確保は関数オブジェクトが概ね解決したところはある
非ウェブ系のGUIにおいてはオブジェクト抜きでは語れないのでは・・・と思ったら誰かが書いてた。ボタンにしろ何しろコントロールは「Object」から派生してたりするし、画面に表示されるのはオブジェクトのプロパティ
動物→ヒト→勇者/、動物→モンスター→中ボスみたいなら状態管理の例になる？
説明のためのサンプルなので、別にひどくない可能性。英語の教科書に出てくる例文が非現実的、とかの難癖と同じに見える。リアルな用例を使うと別の説明が追加で必要になり学習の流れを阻害する、なんてことは多い。
そもそもの話、設計と実装がごっちゃになってる説明が多すぎる。同じ「オブジェクト指向」でも全然別モノなんだから分けて解説しろ！
御意。オブジェクトは「もの」「対象」(部品)であり「目的」(典型的にはアプリケーション)の掛詞ですからね。現状の入門者用の多くは本末転倒ですよね。
アプリケーションといっても受発注のような事務寄りのものから、それこそ物理シミュレーターのようなものやゲームもあるだろうから、この指摘はピンときませんでした。
モバイルアプリもオブジェクトモデリングがいるのってほとんどない。
マジか？さすがにそんなサンプル見たこと無いでｗ。現場にはゴロゴロおるけどなｗ。昔々、パラメータ値を追加するだけに継承クラス作るやつおって言い合いになったなあ。
だいたいヒドい理由どこ
oopsが活かせるのはフレームワークを作る様な場合で、通常のビジネスロジックではそこまで頑張らなくても良いからだと思ってる。素直にoracle/mysql/postgres/mongodb辺りに同一I/Fで接続するクラスの解説がわかりやすいのでは。
抽象型や継承はオブジェクト指向をやりやすくするための言語機能であってオブジェクト指向そのものではないんだが、オブジェクト指向否定派は言語機能を使わなくていいからとオブジェクト指向自体を否定したがる。
決済とか通知とかはオブジェクト指向で作ることが多いかな。業務固有のものは抽象化しづらいからあんまりないかも
「実際のアプリケーションを見据えるとオブジェクト指向機能の使いどころがない」←？「大規模になったら便利なんです！小さいサンプルじゃわからないんです！」←これはそうでしょ。苦労はクラスを作る側が背負う。
一種の宗教戦争だね。
この筆者基礎知識がないのにいつも低俗な煽り記事を書きますね。「継承はだめだけどInputSteamの継承は便利」。モダンな言語は入出力ストリームもクラス継承なんて使わずに全部型クラスベース。Java屋さんは100年遅れてる
"某Java本" https://x.com/kis/status/1943525897753207133 / 個人的には「良いコード/悪いコードで学ぶ設計入門」も大概。こっちにもRPGの例が出てくる
自分でそう作るかはともかく、利用するライブラリはそうなってないと困る。互いに値を共有しない正規表現オブジェクトをいくつも作れないと不便だし
ウェブアプリとか業務アプリって、リレーショナルDBにデータを出し入れする処理でほとんどなんで、この人の言ってる通りだと思う。ゲーム開発とかGUIライブラリそのもを作るのは別だろうけど
単にこれ書いている人がオブジェクト指向をきちんと理解してないからなんじゃないか? OOA(分析)とOOD(設計)とOOP(プログラミング)の三階層に分けて書いてくれないと言いたいことがさっぱりわからんちん
初心者は、1. プログラミングを理解していない、2. オブジェクト指向という概念を理解していない → 理解されてないもの同士を組み合わせてオブジェクト指向プログラミングを説明している → わかるわけねーだろ？よな
初心者向けの情報が求められ続けるのは当たり前です。それを「いつまでたってもなくならない」と言ってる時点でその人の知性レベルが疑われます
オブジェクト指向否定派ってWEBアプリの話ばかりで複雑な業務アプリとかゲーム開発とかのこと考慮しないよね
いまだにオブジェクト思考を受け入れられない人がいるのか。世の中生きづらそうだ
某Java本アレだろうなと思ったらアレだった。でもアレ以外に何も分からん初心者を挫折させずに解説するのも難しそう。どの場面で有効かまで入れると初心者は絶対混乱する
初心者に向けプログラミング教本にオブジェクト指向はテーマが大きすぎると思う。OOA、OOD、OOPと具体化していく過程が必要。
"某Java本" ←多分例の、未だにJavaなのに参照渡しとか教えちゃってる本のことだろうな～ …と思ってたらその通りだった
シンプルにJavaのクラスライブラリが当然うまくオブジェクト指向になっているよねって思う。アプリケーションに当てはめるとほとんど破堤しているような。手続きが多くなり使い辛い。いい完成品を示されないのが原因
実践でオブジェクト指向がどうのとかいうような場面はほとんどない。たまに継承で実装するとテストが楽になる時がある。書いてるプログラムの内容によるが、基礎的な処理の上に種々の応用処理を実装するときに使う。