なぜ「staticおじさん」は叩かれたのか?
■ このスレッドは過去ログ倉庫に格納されています
staticおじさん(読み:すたてぃっくおじさん)とは、2010年に@ITに「実はオブジェクト指向ってしっくりこないんです![1]」 と投稿して炎上したおじさんのことである。 staticおじさんが爆誕した2010年ごろのIT土方界隈ではJavaを中心としたオブジェクト指向が主流であり 「なんでもかんでもオブジェクト指向」という風潮があった。 このためstaticおじさんは多勢に無勢でボロクソに叩かれる結果となり、さらにはプログラミングそのものの 話を飛び出してオブジェクト指向推進派による学歴差別などに発展したすえに無事炎上した。 それからわずか数年後、staticおじさんの主張に「極力static変数は使わない」「関数ポインタを多用する」 というコーディング規約を加えた「関数型プログラミング」がJavaScript界隈を中心に爆発的に流行し、 その流れに乗るかたちでこれら規約を半ば強制する仕様の「関数型プログラミング言語」も多数登場するなど 世界的に一大ブームになった。 ちなみにstaticおじさんの主張と非常に酷似したものが、staticおじさんの登場より遥か昔、インターネットを 支える中核技術である「IP」のRFC(仕様書)にも「階層化の有害性」として書かれていたりする。 また、海外でも同様の主張を面白おかしく書いた「Bjarne Stroustrup インタビュー」なる怪文書が出回り、 こちらも大炎上した。 https://monobook.org/wiki/%E3%82%B9%E3%82%BF%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF%E3%81%8A%E3%81%98%E3%81%95%E3%82%93 >>332 それはDTOだよね DTOはデータ隠蔽しないのが基本だから問題ないよね いまでもValueObjectという名前で使われてるっしょ それはドメインモデル貧血症の例として不適切だと思った 構造化プログラミング未経験症はこれ class A { int value; int result; String msg; void execute() { phase1(); phase2(); phase3(); return msg; } void phase1() { value = 1; } void phase2() { result = value * 2; } void phase3() { msg = "result = " + result; } } DTOはO/Rマッパー等を使う時に利用するデザインパターンだが、ドメインモデル貧血症はアンチパターン。 まぁ、さっき示した具体的なコードがDTOと言えばそうなんだけど...用途の間違えたDTO。 DTOをモデルという名前で呼ぶからドメインモデルとごっちゃになるのかもわからんね DTOはDTO ドメインモデルはDTOとは違うよ ドメインモデル貧血症はこんなところかな class Calc { int calc(Person p) { return p.Sarary * 2; } } 君は具体的にどういう経験をしてドメインモデル貧血症がよくないと思ったのか教えてくれる? 僕はないんだよね、Calcというモデルで計算がしやすくなることもあるし ドメインモデル貧血症はただのレッテル貼りにしか思えない >>337 ドメインモデルとデータが違うのはその通り。 悪かった。真面目にコードを書く。 class Box { public int Height { get; set; } public int Width { get; set; } } これがドメインモデル貧血症 class Box { public int Height { get; } public int Width { get; } public Box(int height, int width) { if (height <= 0) { throw new ArgumentOutOfRangeException(nameof(height)); } if (width <= 0) { throw new ArgumentOutOfRangeException(nameof(width)); } Height = height; Width = width; } public int Area() { return Height * Width; } } これがオブジェクト指向 スマホのお陰で改行が狂ってるかもだが。 >>338 レッテル貼りじゃなくて、本気で困ったことあるから安心しな。 せっかく例を書いてもらって悪いが、ドメインモデル貧血症の例は>>339 を見てくれ。 まず、1つ目のクラスは、セッターとゲッターしか定義されてないだろ? これって実質、ただのC言語構造体と一緒。 ビジネスロジックが書かれてなく、こんなの渡されたクラス利用者は困るわけだ。 なぜって? だって、何もしてくれないじゃん。できることはパラメータのセット・ゲットだけで、データベースに何かを保存してくれる訳でもなければ、計算をしてくれるわけでもない。実質ただの変数。 どちらもオブジェクト指向だよね BoxにAreaメソッドがあるか否かの違いしかないので あった方が便利なら追加すれば良いと思うけど やはりドメインモデル貧血症がダメだとは思えない >>340 次は2個目のクラスだ。 まぁ、できる事は少ないが、これはクラスを利用する意義はある。 値をセットするだけではなく、Box(箱)クラスの名に恥じない機能、面積取得機能が備わってるから。 つまり、これだけでBoxクラスを使う価値が出てくるわけだ。 ...という話なんだ。うん、それだけ。 >>340 Boxクラスはデータを表してるってことでしょ なら何もしなくて正解だし何かしてくれる方が扱いづらい Boxクラスの計算するクラスを作ればいい どういう計算が必要かはドメインによって変わってくるでしょ そうして作られたクラスが本当のドメインモデルだよ >>341 じゃ聞くけど、貴方は前者のBoxクラス渡されても困らないの? 何もできないよ? 俺!Boxクラスのロジック実装します!あなたはBoxを使う処理を書いて!と分業したとき、俺があなたに前者Boxクラスを渡して、面積計算や座標変換(回転等)計算などの処理はそっちでやってください!とか言われたらどうです? >>342 面積が必要なかったら無駄なクラスだしなあ どうして面積を得るのかがわからないと価値があるかどうかはわからないよ 面積を使って何をするのっていう情報がないからドメインモデルではなくて ただのデータだと思った >>344 すごく困るBoxクラスが欲しいと僕は言ってるわけじゃないから そういうの渡されてもすごく困ると思う え、なんで? って思う > 俺!Boxクラスのロジック実装します!あなたはBoxを使う処理を書いて!と分業したとき、 > 俺があなたに前者Boxクラスを渡して、面積計算や座標変換(回転等)計算などの処理は > そっちでやってください!とか言われたらどうです? 頭おかしいのかなって思う >>344 あと、リアルプログラミングってまじで分業するからな。 俺がBoxクラスを使わせるのは貴方だけではない。他の開発者も使う。 そんな最中、getter.setterしかなかったら、皆、どんな反応すると思う? こういうライブラリレベルで使い勝手の良いコードを隅々まで書くのが俺の開発現場。 あ、でも面積計算クラスや座標変換クラスでまとめるのは場合によってはありかもね 僕はそういうドメインモデル貧血症は良いと思ってる立場だから、それはありですね >>346 へぇ。じゃ、前者のテストコード書いてよ。 >>347 そうなの? Boxクラスが出てくるあたりゲームプログラマの人? 僕はBtoBの業務アプリが主だけど、分業するときってクラス単位じゃなくて アクターとか機能とか大きな単位で分けるから、何言ってるのかよくわからない >>348 > 僕はそういうドメインモデル貧血症は良いと思ってる立場だから、それはありですね 分かってくれてありがとう。 でも、年のために言うと、ドメインモデル貧血症は前者の例ね。 まぁ、言葉の定義より、どんなコードの書き方が役に立つかの方が重要なんだけど...どうしても、staticおじさん論争になると言葉の定義は外せないのが辛いところ...。 あと、ごめんなさい。>>349 は無視してください。 世に出ているservlet, jsp, spring とかの本では APIとしてはオブジェクト指向が登場するけど プログラムを書く側はオブジェクト指向を意識して書いてないぞ >>351 なんか誤解してるような気がするんだけど Boxに面積の計算を持たせない前者の例で、面積の計算を面積計算クラスにまとめると ドメインモデル貧血症になるけどそれはありだよねっていうのが僕が言いたかったことだよ 計算は僕が携わっているドメインだと結構変わるのよ、顧客満足のためだったり 法律のためだったり世の中の情勢に配慮したりとかで、その場合は個々のデータに 計算をもたせるよりも計算だけを行うようモデリングしたほうが都合がよかったりする ドメインモデル貧血症にはなるけどシステムとしてはそちらの方が適切だからそうすることもある 君は分業することを例にドメインモデル貧血症がダメだといったけど、それは コミュニケーションの問題だと思うんだよね、自分は面積の計算を実装してもらいたくて 相手は面積の計算を実装しなくて良いと思ってたというコミュニケーションミスだと思うんだよね そういうコミュニケーションで解決するべき問題をオブジェクト指向の問題にするべきではないと思うよ 初めて聞いた言葉だから自信ないけど、 オブジェクト指向設計のアンチパターン 貧血ドメインモデル(英語版)ビジネスロジックが欠けたドメインモデル。オブジェクトは属性と振る舞いを持たなければならないので、オブジェクト指向プログラミングではない ってwikiに書いてあった (よく意味を理解していない) >>353 ドメインモデルが必要なほど複雑な要件は入門書では扱われないからね・・・ 現実は要件がころころ変わることに対応しないといけなかったりで オブジェクト指向をきちんと理解して実践してると助かることはままある リクエストごとに処理をごりごり書いたトランザクションスクリプトで十分なことは多いし フレームワークが提供してるライブラリで処理を完結できるほどフレームワークの機能が 充実してきてることもあるんじゃないかな >>355 ドメインモデル貧血症はマーチン・ファウラーという猥褻顔のおっさんがアンチパターンと言ってて そのおっさんが言うんならそうなんだろと思考停止で鵜呑みにしてる人がほとんどで 実際にプログラム書いてみるとドメインモデル貧血症はそんなに悪くない スリムドメインモデルと言い換えて風評被害をなくしたい、ご協力よろしくお願いします これまでの話をまとめると、staticおじさん良いよねってこと スレタイさん「なんでstaticおじさんは叩かれたの?」 叩いた人がアホだったんだと思う とくにAC/DCって人はstaticおじさんが悪くなるように物事を解釈して 議論をダメにしてると思った >>359 > これまでの話をまとめると、staticおじさん良いよねってこと 嘘だゾ さっき、ドメインモデル貧血症はオブジェクト指向ではないvsオブジェクト指向だ、で衝突しているのを見てたゾ どこにも、staticおじさんを褒めてる要素がなかったゾ しかも、オブジェクト指向でも何でもないプログラムをオブジェクト指向のアンチパターンとして紹介して論破されてるところ見たゾ >>362 落ち着きなよ、全部君の気のせいだよ、はい論破 >>360 知ったか知識で誤ったクラスの使い方を説明したから 更に、コメ欄で学歴差別発言をみながわけんじがしたから 揚げ足取りばかりのコメントに東工大の圧力で対抗するのは適切だよ 東北大学で情報工学学んで東工大の大学院に入ったとしたらすごい経歴だな 東京工業大学の汚点になるから、こんなボケたジジイを持ち上げるのやめて欲しい。 staticおじさんはSIerに仕事発注する立場でありながら自分でシステム構築もしてるようだな エンジニアの理想じゃん アラン・ケイがオブジェクト指向という言葉を作って オブジェクト指向のプログラミング言語Smalltalkを作った 日本IBMはSmalltalkのスペシャリストを集めてSmalltalkを使って オブジェクト指向のシステムを作ろうとしたけど失敗した 長野オリンピックや九州医大病院のシステムだ 結局それらはVBで作られた 最強の組織、最強の言語、最強のオブジェクト指向を使っても できなかったことがVBならできた このことから僕たちは学ばないといけないよね 過剰なオブジェクト指向は破綻を招くのじゃなかろうかと >>373 過剰なオブジェクト指向かどうかはさておき それよりも先に単にクラス設計の時点でカンタンに間違うと思う OOPやOOPLそのものの問題より先に、クラス設計というところで単に間違うと思う staticおじさんもデザインパターン厨もどっちも嫌なんだよ〜ん 俺は全部日本語で書くおじさんだけど叩かれる? DDDとかもう古いかな 小規模スマホアプリならstaticで良いよね 他のオブジェクトと協調なんてしないから状態の奪い合いなんて起こらない Enumを全角の日本語にすることはある 気は進まないが英語やローマ字だと可読性が低すぎてバグに繋がりそうなとき 言うほど悪い人じゃなかったよね(´・ω・`) 一理はあったし、かわいそう(´・ω・`) メソッドもメンバ変数もstaticにしてインスタンス化を不要にするが何故駄目なのかようやく分かったよ ホラ吹きプログラマーに流されて擁護したことが恥ずかしくなってきた ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる