Lie 2：コードは世界のモデルを中心に設計すべきですか？[閉まっている]

最近、Three Big Liesのブログ投稿を読みましたが、2番目の嘘を正当化するのに苦労しています。

（嘘＃2）コードは世界のモデルの周りに設計されるべきである

コードが架空の世界の何らかのモデルまたはマップであることには価値がありません。一部のプログラマにとってこれがなぜこれほど魅力的であるかはわかりませんが、非常に人気があります。ゲームにロケットがある場合は、「ロケット」クラス（コードはC ++であると仮定）があり、これには1つのロケットのデータのみが含まれ、ロケットのような処理を行うことをご安心ください。どのデータ変換が実際に行われているか、またはデータのレイアウトはまったく考慮されません。または、1つのことはどこにあるのかという基本的な理解がなければ、おそらく複数あります。

この種の設計には多くのパフォーマンス上のペナルティがありますが、最も重要なことは、スケーリングしないことです。まったく。ロケット100個のコストは、ロケット1個の100倍です。そして、それ以上の費用がかかる可能性が非常に高いです！プログラマーでなくても、それは意味をなさないはずです。規模の経済。何かがもっとあるなら、それはもっと高くなくて、より安くなるはずです。そして、それを行う方法は、データを適切に設計し、同様の変換によって物事をグループ化することです。

特にこの嘘に関する私の問題はここにあります。

1. 想像上の世界をモデル化することは、コードを視覚化して整理するのに役立つので、仮想的な世界のモデル/マップであるコードには価値があります。

2. 「ロケット」クラスを持つことは、私にとって、クラスにとって完全に有効な選択です。「ロケット」は、AGM-114ヘルファイアなどのタイプのロケットに分類できます。これには、ペイロードの強度、最大速度、最大旋回半径、ターゲットタイプなどが含まれますが、発射されるすべてのロケットには位置が必要ですそして速度。

3. もちろん、100個のロケットを所有するには1ロケット以上かかります。画面上に100個のロケットがある場合、それらの位置を更新するには100個の異なる計算が必要です。2番目の段落は、100個のロケットがある場合、状態を更新するのに100未満の計算コストが必要だと主張しているように聞こえますか？

ここでの私の問題は、著者が「欠陥のある」プログラミングモデルを提示しているが、それを「修正」する方法を提示していないことです。おそらく、ロケットクラスの類推につまずいているかもしれませんが、この嘘の背後にある理由を本当に理解したいと思います。代替手段は何ですか？

まず、いくつかのコンテキストを見てみましょう。これは、Cell BE CPUのパフォーマンスの最後の低下をテーマにしたブログを書いているゲームデザイナーです。つまり、コンソールゲームプログラミング、具体的にはPlayStation 3用のコンソールゲームプログラミングについてです。

現在、ゲームプログラマは好奇心b盛で、コンソールゲームプログラマはさらに好奇心が強く、Cell BEはかなり奇妙なCPUです。（SonyがPlayStation 4の従来のデザインを採用した理由があります！）

したがって、このコンテキスト内でこれらのステートメントを調べる必要があります。

また、そのブログ投稿にはいくつかの簡略化があります。特に、この嘘＃2はあまり提示されていません。

私は、現実世界から抽象化されたものはすべて、ある意味でモデルであると主張します。また、ソフトウェアは現実ではなく仮想であるため、常に抽象化であり、したがって常にモデルです。しかし！モデルは、実世界へのクリーンな1：1マッピングを持つ必要はありません。それは、結局のところ、そもそもそれをモデルにしているのです。

だから、ある意味で、著者は明らかに間違っています。ソフトウェアはモデルです。期間。ある他の意味で、彼は正しい。そのモデルは実際には現実の世界にまったく似ている必要はない。

私は、長年にわたって他のいくつかの回答ですでに示した例を示します。OO101銀行口座の（有名な）紹介です。ほぼすべてのオブジェクト指向クラスで銀行口座は次のようになります。

class Account {
  var balance: Decimal
  def transfer(amount: Decimal, target: Account) = {
    balance -= amount
    target.balance += amount
  }
}

だから：balanceはdataでありtransfer、操作です。

しかし！これは、ほとんどすべての銀行ソフトウェアで銀行口座がどのように見えるかを示しています。

class TransactionSlip {
  val transfer(amount: Decimal, from: Account, to: Account)
}

class Account {
  def balance = 
    TransactionLog.filter(t => t.to == this).map(_.amount).sum - 
    TransactionLog.filter(t => t.from == this).map(_.amount).sum
}

したがって、現在transferはデータでbalanceあり、操作です（トランザクションログの左折）。（またTransactionSlip、不変でbalanceあり、純粋な関数でTransactionLogあり、追加のみの「ほぼ」不変のデータ構造であることに気付くでしょう...最初の実装で目立った同時実行バグを発見したことは間違いないでしょう。 ）

これらは両方ともモデルであることに注意してください。これらは両方とも同等に有効です。これらは両方とも正しいです。これらは両方とも同じことをモデル化します。しかし、それらは互いにまったく二重です。1つのモデルのデータであるすべてが他のモデルの操作であり、1つのモデルの操作であるすべてが他のモデルのデータです。

したがって、問題は、コードで「実世界」をモデル化するかどうかではなく、どのようにモデル化するかです。

結局のところ、2番目のモデルは実際には、銀行が実際の世界でどのように機能するかでもあります。私は上記で示唆したように、この第2のモデルでは、時間ではないが長すぎる前に、どこがあったことを考慮すれば、実際には非常に重要である、並行処理のバグのほとんどは不変と純粋、そして免疫があるTransactionSlipのだった実際の周りに送られた紙の伝票馬と馬車で。

ただし、この2番目のモデルが実際のバンキングの仕組みと実際のバンキングソフトウェアの仕組みの両方に実際に一致するという事実は、それを自動的に何らかの「正しい」ものにするわけではありません。実際、最初の（「間違った」）モデルは、銀行の顧客が銀行をどのように見ているかにかなり近いためです。それらを、transferある操作（彼らはフォームに記入しなければならない）、とbalanceの一部であるデータ自分のアカウント文の一番下にあります。

そのため、高性能PS3シューティングゲームのコアゲームエンジンコードにはRocketタイプはありませんが、モデルが奇妙に見えても、進行中の世界の一部のモデリングが存在することは事実ですコンソールゲームの物理エンジンプログラミングの分野の専門家ではない人に。

彼が提案するすべての「嘘」には同意しません。

TL; DRこの記事の著者は、彼らの記事をより面白くするために物議を醸そうとしていましたが、いわゆる「嘘」は正当な理由でソフトウェア開発者に受け入れられています。

うそ＃1-ビッグOはスケーリングの目的で重要です。小さなアプリケーションが唯一の時定数の問題であるより長い時間がかかるかどうかは誰も気にしません。入力サイズを2倍にしても実行時間が10倍になることはありません。

嘘＃2-現実の世界に合わせてプログラムをモデル化することで、プログラマは3年後にコードを見て、それが何をしているのかを簡単に理解できます。コードは保守可能である必要があります。そうでないと、プログラムが何をしようとしているかを理解しようとするだけで何時間も費やす必要があります。別の答えは、LaunchPadやなどのより一般的なクラスを持つことができることを示唆していますMassiveDeviceMover。これらは必ずしも悪いクラスではありませんが、Rocketクラスが必要です。誰かが何をするのMassiveDeviceMoverか、それが何を動かすのかをどうやって知るのでしょうか？それは動いている山、宇宙船、または惑星ですか？これは基本的に、クラスのようなものを追加MassiveDeviceMoverすると、プログラムの効率が低下することを意味します（ただし、読みやすく、理解しやすくなります）。

さらに、開発者の時間のコストはずっと前にハードウェアのコストを超え始めました。最適化を念頭に置いて設計しようとすることから始めるのは恐ろしい考えです。簡単で理解しやすい方法でプログラムを作成し、プログラムのどの部分が実行に多くの時間を費やしているかを見つけた後、プログラムを微調整します。忘れないでください：実行時間の80％がプログラムの20％によって使用されています。

嘘＃3-コードは非常に重要です。よく書かれた（そしてモジュール化された）コードにより、再利用が可能になります（無数の工数を節約できます）。また、不正なデータを選別して認識できるため、処理できます。データは素晴らしいですが、コードがなければ、分析して有用な情報を取得することはできません。

電子商取引システムでは、クラスレベルで「ロケット」を扱うのではなく、「製品」を扱います。ですから、それはあなたが何を達成しようとしているか、そしてあなたが望む抽象化のレベルに依存します。

ゲームでは、ロケットは多くの種類の「動く物体」の1つにすぎないと主張できます。他のすべての移動オブジェクトと同じ物理学がそれらに適用されます。したがって、少なくとも「ロケット」は、より一般的な「移動オブジェクト」の基本クラスから継承します。

いずれにせよ、あなたが引用した文章の著者は、彼の主張を少し誇張しているようです。ロケットには、「燃料の残量」や「推力」などの独自の特性がありますが、100個のロケットでこれを表すために100個のクラスは必要ありません。必要なのは1個だけです。オブジェクトの作成は、ほとんどの適切なプログラミング言語ではかなり低コストです。したがって、ロケットのようなものを追跡する必要がある場合、Rocketオブジェクトは高価すぎる可能性があるため、Rocketオブジェクトを作成すべきではないという考えはあまり意味がありません。

現実の世界での問題は、そのようなひどい物理です。現実の世界では物事を物理的なオブジェクトに分離します。なぜなら、それらは個々の原子やロケットである可能性のある何かの巨大な溶融スラグよりも動きやすいからです。

同様に、現実の世界は、私たちが依存している多くの便利な機能を提供します。「...を除くすべての鳥が飛ぶ」というペンギンの例外を作るのは本当に簡単です。そして、物事をロケットと分類することは本当に簡単です。つまり、そのペンギンをロケットと呼び、それを照らすと...それはうまくいきません。

したがって、現実の世界で物事を分離する方法は、これらの制約の下で概念的に機能します。コードで物事を行うときは、明らかに異なるこれらの制約の下でうまく機能するように物事を分離する必要があります。

代替手段は何ですか？

ネットワークについて考えてください。ポート、ワイヤ、およびルーターをコードでモデル化しません。代わりに、ネットワーク通信を接続とプロトコルに抽象化します。これは、実世界での実装に関係なく有用な抽象化であるためです。そして、コードでのみ重要な有用な制約（たとえば、接続が開かれるまで通信できません）を配置します。

そう、実世界が機能した後にコードをモデリングすることもありますが、それは偶然です。人々がOOPについて話すとき、オブジェクトは現実世界のオブジェクトではありません。そうでなければ学校やチュートリアルは数十年の悲劇だと言う。

別の方法は、プログラムが気にすることをモデル化することです。プログラムがロケットを扱う場合でも、というエンティティを必要としない場合がありますRocket。たとえば、LaunchPadエンティティとLaunchScheduleエンティティとエンティティがありMassiveDeviceMoverます。これらすべてがロケットの打ち上げに役立つという事実は、ロケット自体を扱っているという意味ではありません。

ここでの私の問題は、著者が「欠陥のある」プログラミングモデルを提示しているが、それを「修正」する方法を提示していないことです。おそらく、ロケットクラスの類推につまずいているかもしれませんが、この嘘の背後にある理由を本当に理解したいと思います。代替手段は何ですか？

これは本当の問題ですが、開発者としての私の考えをお伝えします。

まず、一般的な誤解として、私はそれが嘘だとは言いません。それを嘘と呼ぶのは誇大宣伝です。

ある意味で彼は正しい。これに多くの時間を費やすつもりはありません。それは問題の一部ではないからです。しかし、本質的に彼は正しい。これを「ラボで機能するものは実際の生活では機能しない可能性がある」と言い換えることができます。開発者は、「ラボ」で動作する設計に固執しますが、実際のアプリケーションでは失敗します。

Three Soundsは私には少し石鹸のように聞こえますが、基本的に彼は再び正しいです。ただし、これは「ニーズに合わせてコードを記述し、コードにニーズを合わせようとしないでください」に書き換えることができます。

二つの繰り返しには、ここで彼は正しいです。単純な「乗り物」クラス、またはさらに単純な「可動」クラスが機能する場合、開発者が「ロケット」クラスの開発に数週間以上費やしているのを見てきました。ロケットが画面の左側から右側に移動して音を出すだけであれば、車、電車、ボート、ハエと同じクラスを使用できます。100は、1 * 100未満の引数のコストが開発に費やされた時間であり、計算コストではあまりないようです。再利用できる一般クラスの数を減らすことは「安価」ですが、再利用できない多くの特定のクラスです。これはおそらく「一般クラスは特定のクラスよりも優れているため、

本質的に、記事全体をより少ない流行語で書き直すことができ、それはせいぜい長い段落に過ぎません。とはいえ、それはプログラミングの狭い領域に焦点を当てたブログ投稿です。私はいくつかの組み込みプログラミングを行ってきましたが、これらのステートメントの背後にある一般的な考え方に同意することができますが、GDCでのプレゼンテーションに適したものにするためにそれらの周りにかなりの「ふわふわ」があります。

最後に、この記事は2008年に執筆されました（私が知る限り）。物事は急速に変化します。今日の声明は真実ですが、組み込みシステムは当時よりはるかに一般的であり、開発パターンが変わります。おそらく、この記事/トークに応えてでも。

プラットフォーム、メモリ使用の効率、およびデータという学術的な懸念がこれらの中心にあるのは興味深いことです。しかし、人間の要素は完全に無視されます。

ソフトウェアは、人々のニーズを満たすことです。通常、これはビジネス用語で定量化されます-何かを望む顧客と、それを実現するために喜んで支払う支援者がいます。方程式の両側のニーズを満たすようにソフトウェアが作成されている場合、それは良いソフトウェアであり、そうでない場合は悪いソフトウェアです。

プラットフォームが顧客にとって重要でない場合、プラットフォームは重要ではありません。顧客にとってメモリ効率が重要でない場合、それは重要ではありません。データが顧客にとって重要でない場合、データは重要ではありません。コードは機能するが、読み取りや保守ができず、顧客が適切な価格で迅速かつ信頼性の高い変更を望んでいる場合、不適切に記述されたコードは悪いことです。コードは機能しますが、読み取りや保守ができず、顧客が高額なリファクタリングを気にかけない、または支払おうとする場合、コードの記述が不十分であることは良いことです。

大きな嘘は、人間の要素以外は重要だということです。データが重要な理由 それが必要な顧客や利害関係者がいるからです。それが「大きな真実」です。

私見コードが「世界のモデルを中心に設計されている」なら、デザイナーと開発者、そしてメンテナーの両方にとって理解しやすいです。しかし、それは私だけでなく、ソフトウェアだけではないと思います。ウィキペディアから：科学モデリングは科学活動であり、その目的は、世界の特定の部分または機能を、既存の通常一般に受け入れられている知識を参照することにより、理解、定義、定量、視覚化、またはシミュレートしやすくすることです