タグ

オブジェクトに関するene0kcalのブックマーク (11)

  • ゲームで「壁すり抜けるバグとかどうなってんだ!?」ってよく言われるけど実際作ってみると「逆」だと分かる

    なぎせ ゆうき @nagise ゲームで 「壁をすり抜けるバグどうなってんだ!?」 みたいに言われがちですけども、プログラミングやると 「すり抜けない衝突判定、どうやってんだ!?」 ってなりますからね🤔 2022-09-28 17:07:17 リンク Wikipedia 衝突判定 衝突判定(しょうとつはんてい、Collision Detection)とは、「2つ以上のオブジェクトの交差を検出する」という計算機科学上の問題であり、具体的には「ある物体が別の物体に当たったか(衝突したか)どうか」を判定するプログラム処理のことを指す。ロボット工学、計算物理学、コンピュータゲーム、コンピュータシミュレーション、計算幾何学など、さまざまなコンピューティング分野で応用されている。 衝突判定のアルゴリズムは、2Dオブジェクト同士の衝突判定と3Dオブジェクト同士の衝突判定に分けることができる。 ビ 14

    ゲームで「壁すり抜けるバグとかどうなってんだ!?」ってよく言われるけど実際作ってみると「逆」だと分かる
    ene0kcal
    ene0kcal 2022/10/03
    1/60秒の世界ではオブジェクトは点(座標)でしか存在しないので、次フレーム秒では飛び越してるパターンや別オブジェクトに衝突パターン等がある。さらに飛び越え別オブジェクト衝突が連続するともう訳分からんよ。
  • なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena

    1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から

    なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
  • メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌

    「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と

    メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
  • Windowsにおけるフォルダーとディレクトリとは (1/2)

    Windowsにおいて、「フォルダー」と「ディレクトリ」は 実は厳格に区別されている Windowsにおけるフォルダー(Folder)とディレクトリ(Directory)の違いをご存じだろうか? Windowsにおいてフォルダーとは、「仮想フォルダー」(Virtual folder)と「ファイルシステムフォルダー」(File system folder)からなるオブジェクトであり、ディレクトリとはファイルシステムフォルダーのみを指すオブジェクトだ。MS-DOS時代には、仮想フォルダーがなかったので、すべてディレクトリーと呼んでいた。 このため、今でもフォルダーの意味でディレクトリと呼ぶ人がいて、意味が曖昧になっているが、少なくともWindowsの中では厳密に区別されている。レジストリのHKEY_CLASSES_ROOTにあるprogidの中に「Folder」「Directory」があり、そ

    Windowsにおけるフォルダーとディレクトリとは (1/2)
    ene0kcal
    ene0kcal 2022/01/24
    なるほどわからん(わかった)。
  • アプリケーションをドメインモデルで設計する - Qiita

    親記事 : https://qiita.com/Regpon/items/1116679adadd8fb76f3f ドメインモデルで設計する狙い オブジェクト指向プログラミングにおいてかなり重要な内容となっているが如何せん概念的な内容となっている。ドメインモデルを設計するには幾度とない失敗の経験を重ねていき、常に改良していく精神が重要。そのための指針となる内容なので是非とも押さえておきたい。 それを踏まえてドメインモデルで設計する狙いは以下の通り。 業務的な判断・加工・計算のロジックを重複なく一元的に記述できる 業務の関心事(データ)とコードを直接対応させ、どこに何が書いてあるのかわかりやすく整理する 業務のルールの変更や追加の時に、変更の影響を狭い範囲に閉じ込める ドメインモデルの設計の難しさ ドメインモデルの設計は手続き型(スクリプト型)のプログラミングと比べて設計がむずかしいとされる

    アプリケーションをドメインモデルで設計する - Qiita
  • ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える

    『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう

    ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
  • Immutable.jsとImmer、ちゃんと使い分けていますか?

    昨今のフロントエンド開発では、データをイミュータブルなオブジェクトとして扱うのが主流です。すなはち、データが変わるときはオブジェクトを書き換えるのではなく、新しいデータを持った新しいオブジェクトを作ります。最近ではオブジェクトがデータとしてプログラムのあちこちで取り回されることが増えて、一度余所に渡されたデータの中身が後から変更されるのは混乱をきたし設計が困難になるというのが主な理由です。 データを変更するたびに新しいオブジェクトを作るのは、特にデータが複雑になったりネストしたりしていると面倒だしプログラムの見通しが悪くなります。そこで使われるのが、データをイミュータブルに扱うためのライブラリであるImmutable.jsとImmerです。 データをイミュータブルなものとして扱うという目的はどちらのライブラリでも達成することができますが、現在では Immer のほうが開発が活発であり、独自

    Immutable.jsとImmer、ちゃんと使い分けていますか?
  • Pythonのオブジェクト指向プログラミングを完全理解 - Qiita

    オブジェクト指向 1. オブジェクト指向の起源 2003年チューリング賞の受賞者アラン・ケイさんはよくオブジェクト指向プログラミングの父と称されます。ご人も憚ることなく、幾度、公の場で発明権を宣言しています。しかし、ケイさんは「C++」や「Java」などの現代のオブジェクト指向言語を蔑ろにしています。これらの言語は「Simula 67」という言語を受け継いだもので、私が作った「Smalltalk」と関係ないのだとケイさんは考えています。 オブジェクト指向という名称は確かにアラン・ケイさんに由来するものです。しかし、C++Javaで使われている現代のオブジェクト指向は当初のと結構違います。ケイさん自身もこれらの言語を後継者として認めないです。では、ケイさん曰くC++Javaの親であるSimula 67という言語はどんな言語でしょうか。ここで、簡単なサンプルコードを見てみましょう。 Cl

    Pythonのオブジェクト指向プログラミングを完全理解 - Qiita
  • 型クラスはインターフェースとどう違うのか | POSTD

    (注:2017/02/27、いただいたフィードバックを元に翻訳を修正いたしました。) Haskellの型クラスは、Haskellを学び始めたばかりの多くの人にとっては難しい概念です。たいていの言語はこれを表すことが全くできませんし、それに近い概念も持っていません。多くのオブジェクト指向型の言語にとっては、利用可能なものの中では Interface が最も近い言語要素でしょう。Rubyの modules は似たような役割を持っています。しかし、この概念は両方とも、名前の多重定義と一種のポリモーフィズムをアドレスするので、型クラスが提供するパワーの一部を欠いています。 この記事は、型クラスに興味を持っている人向けです。Haskellや関数型プログラミングの予備知識は必要ありません。JavaやC言語のような静的な型付き言語に慣れていれば、役に立つでしょう。 型クラスについての概要/要約 型クラス

  • 最強オブジェクト指向言語 JavaScript 再入門!

    この資料では、JavaScript でオブジェクト指向プログラミングを行う際に備えておくことが望ましい、基礎知識や概念について解説します。 【対象者】 ・JavaScript でアプリケーションを構築できる方 ・JavaScript におけるオブジェクト指向プログラミングの 実現手法や原理への理解を深めたい方 ・Java 的なクラスベースの言語との違いに違和感や混乱を 感じてらっしゃる方Read less

    最強オブジェクト指向言語 JavaScript 再入門!
  • クラスが持つ3つの役割 - 西尾泰和のはてなダイアリー

    某所のチャットで話題になって、流れ去りそうだったのでもったいないから転載しておいた。事後承諾で。 MIYAMOTO Daisuke: 型の継承と実装の継承を区別する方法がないんだよな。 西尾泰和(nishio.hirokazu): 型を継承させずに実装を継承させたい→それ移譲で ってことかな? MIYAMOTO Daisuke: そそ。そもそも、クラスに「型としての役割」と「実装としての役割」という複数の責務があることに、俺は長い間気づかなかった。これに気づかないと、型継承と実装継承が頭の中で整理できない。 西尾泰和(nishio.hirokazu): 僕が最近気づいたことも加えると、クラスには「ユーザ定義型」「インスタンスを作成する道具」「実装の再利用の単位」という3つの役割がある。 MIYAMOTO Daisuke: あぁ、インスタンスの生成器ね。 西尾泰和(nishio.hiroka

    クラスが持つ3つの役割 - 西尾泰和のはてなダイアリー
  • 1