序文
2006年、私はゲーム業界に入りました。当時はオブジェクト指向プログラミングが流行しており、コードを書き始める前にクラスを設計し、インターフェイスをしっかり書きます。
当時、まだ手続き型のプログラミングをしていたら、"オブジェクト指向の考え方は未熟だ "と見下され、皮肉を言われたことでしょう。
2012年、Unityの台頭により、コンポーネント化された開発がゲーム業界で急速に爆発し、すべてがコンポーネントとなりました！
「コンポーネントを書いて終わり」「これではコンポーネントマインドを使いこなせていない」、おなじみの皮肉がまた襲ってきます。
2018年、およびECSアーキテクチャ、エンティティ、コンポーネントデータ、コンポーネントデータ、コンポーネントのさまざまなデータが含まれているシステム、エンティティのインスタンスの上昇は、メソッドが含まれていない、システムは、特定の関数のアルゴリズムを完了するには、データは、エンティティから来るでコンポーネントデータ。そう高度なああ、この666。
しかし、お気づきでしょうか。ECSは、アルゴリズムが純粋なデータ構造を扱う、C言語のプロセス指向モデルに戻っているのです。
システム 関数とメソッド、エンティティ純粋データエンティティは、C言語の関数＋構造体ではない？プロセス指向はダメって言ってなかった？どうしてECSが復活したの？
「コンポーネント化された開発は時代遅れ。
うそつけ！あなたが中学生だった頃、私はC言語で開発しました... ...
特定の建築パターンに盲目的にこだわらないこと
新しいアーキテクチャーや設計のアイデアが出てきたら、まずそれが何なのか、どんな問題を解決するのか、どんな利点があるのか、どんな欠点があるのか、本質は何なのかを詳しく理解することが重要です。
時代遅れの建築のアイデアなどありません。問題をシンプルに解決するものこそ、良いアプローチなのです。
例えば、コンポーネント化された開発で、ゲームを素早く、安定的に、バグなく開発でき、要件を満たせるのであれば、なぜECSに変更するのでしょうか？
Linuxの "everything-is-a-file "の設計思想とパターンは変わっていません。
C言語のプロセス指向の設計アプローチは、GCC、Git、Linux、FFMPEG、Redis、Nginxなどの古典的なフレームワークやツールの作成につながりました。
コードの確かな基礎、基盤となるOSの確かな基礎、システムの構造に関する完全な知識があれば、これらのデザインパターンをマスターすることができます。問題解決から出発するフレームワーク設計は、問題解決から出発し、問題をよりよく解決するために問題に立ち戻ります。
**問題そのものに立ち戻る、あらゆるデザインパターンのアイデア。**どのような問題を解決し、どのような利点がありますか？ デザインパターンを実践でまとめ、実践で使って問題を解決することで、自分の思考に苦痛を与えるのではなく、「まやかしはまやかしに勝る」という領域を実現します。
建築家として成長するには
1、**最初に言語のコアメカニズムと動作原理に習熟し、その後、タッチ。** 言語が良い、どの言語が悪い議論するために出てくることはありません、まず、前に理解するために言語を使用しています。たとえば、ローカル変数はどこに割り当てられていますか？ 新しいオブジェクトのためのメモリはどこに割り当てられていますか？ゴミ収集とは何か、メモリの断片化とは何か、その原因は何か、など。
2,**良いコーディングの習慣を開発し、コードの結果を知ることができるコードを記述します。**多くの学生は、コードが標準化されていない書き込み、常に3つを失う、自分のコードを書いて、結果は、問題は、すべてのデバッガに依存しているものを言う、エラーを分析する方法を知りません。自分自身が明らかに結果が何であるかを知ってダウンするコードの各行を開発できるようにするには、オーバーヘッド、時間の複雑さ、空間の複雑さなどの実装は、コードの各行は、番号を持っている習慣の中心を行うように言うことができます。
3は、**データ構造と古典的なアルゴリズムに精通していない、アーキテクチャを漫然としないでください。** 連鎖表を設計する方法、動的配列を設計する方法、メモリプールを作成する方法、ハッシュテーブルを実装する方法、ツリーを設計する方法、グラフを設計する方法、特定のアルゴリズムの時間の複雑さは何ですか？空間の複雑さとは？最短経路、AStar経路探索、ソートなど。これらの古典的なアルゴリズムやデータ構造をマスターし、素手で実装しなければなりません。なぜなら、最終的にアーキテクチャの着地はそれらに依存するからです。
4、**オープンソースのコードを読んで、優れたアーキテクチャ設計を学びます。** 完全な知識システムを構築した後、熟練したデータ構造、プログラミング言語のメカニズムに精通。この時間は、方法論とアーキテクチャの問題を解決するために他の人から学ぶことができる、あなたはいくつかのオープンソースのフレームワークやツールを読むことができますが、決して兄弟のNBプロジェクトが、本当のオープンソースは有名な、Redis、nginx、Linuxカーネルおよびその他の関連業界などのフレームワークを使用してされている、オープンソースのフレームワークの本当のスター。
まず第一に、要件を分析し、最終的にどのような問題を解決するためのフレームワークは、最初に関連する理論的な知識と基礎を学び、フレームワークの基本的な使用を理解するために。
ソースコードのディレクトリ構造を分析し、問題から出発し、フレームワークがどのように問題を解決するために展開されているかを参照してください、どのように構造、分割と征服に問題をオンにします。問題の焦点で、フレームワークを読んで、これらの問題を解決する方法、巧みに使用されるデータ構造、問題のいくつかを克服する方法、どの機能を実装し、どの機能を達成するためにユーザーに任せ、どのようにユーザーにインターフェイスを開くので、トレードオフの理由は何ですか？積み重ね、考え続けることで、デザインの考え方やテクニックが理解できるようになります。
最終的に、データ構造とコードをマスターし、完全な知識体系を持ち、実際の問題解決から出発し、問題解決に最適なソリューションを選択できるようになると、自分自身の設計とフレームワークを形成することができ、対応するプロジェクトの機能と要件を完了するために会社のチームを編成することができます。どのようなモデルに関しては、それは問題ではありません。
# #結論
黄色い猫、黒い猫、ネズミを捕まえるのはいい猫。
デザインという点では、問題を簡単かつ迅速に解決する方法が良い方法であり、良いモデルです。
勉強に関する質問はコメント欄で受け付けています。後で回答する時間を設けます。
