なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
JavaScriptの参照レコードとthisバインディング
JavaScriptの仕様には「参照レコード」という概念があります。参照を意識することで、JavaScriptにおけるメソッド呼び出しの理解と左辺式の評価順序の理解を同時に深めることができます。本稿ではこの「参照レコード」の動機と詳細の説明を試みます。 ※ 本記事ではECMAScriptの規格で「参照レコード」と呼ばれている概念を説明します。JavaScriptのオブジェクトは参照渡しのような使い方ができますが、これは本稿で説明する「参照」とは少しだけ異なります。 参照レコードの目的 JavaScriptにおける参照レコードは以下の2つの目的で存在しています。 左辺式の中間評価結果を表現するため。 メソッドのレシーバーを決定するため。 左辺式の中間評価結果とは たとえば a[f()] += 2; というコードを考えます。 function f() { console.log("f()");
ドメインオブジェクトの責務について - Qiita
設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven design)」の原則に従うことが大きいとされています。 この書籍によると、「責務」には以下が含まれるそうです。 「4.1 責務とは何か」 オブジェクトが行う動作 オブジェクトが持つ知識 オブジェクトが他に影響を与える主要な判断 これらの言葉を身近な言葉で置き換える
ドメインモデルをコードへ落とす 〜あなたのクラスは、どこから？〜 - Qiita
annotation: 現在コメントいただいている通り、一部誤りを含んでいる様です。 追って確認・修正いたしますが、現行ではコメントも合わせてお読み頂ければと思います。 こんにちは、風邪はだいたい喉から来るぷーたんです。 「DDDの構成要素はこれだー」というのはたくさんあったのですが、 「このドメインオブジェクトはどの要素だー」と逆引きするものがなかったので調べてフローチャートにしてみました。 例えばドメインモデル図とコードがうまく合致しない時の見直しなどに使えるのではと考えています。 ではご覧ください♪ 検討フローチャート 図1.フローチャート 1) 複数のドメインオブジェクトを扱い、整合性を担保するか まず複数のドメインオブジェクトを扱うかを考えます。 ドメインモデル図では集約線が引かれていたり、複数の関係線が引かれていたりします。 図2.ドメインモデル図の例 上記のような場合であれば
ドメイン駆動設計と関数プログラミングをScalaで - Qiita
はじめに この記事は Scala Advent Calendar 2016 - Qiita の 7 日目の記事です。 私事で恐縮ですが、今年の個人的なハイライトは、遅まきながらドメイン駆動設計と関数プログラミングを学べたことでして、その中でも、"Functional and Reactive Domain Modeling" (Debasish Ghosh 著) (以下、FRDM本) を読んで、ふたつのコンセプトが自分の中で繋がったことが最も大きなものでした。 Manning | Functional and Reactive Domain Modeling この記事では、本書の紹介も兼ねて、ドメイン駆動設計がどのように関数プログラミングと結びつくのか、非常にざっくりではありますが、Scala で表現してみたいと思います (ちなみに、私の Scala 歴は3ヶ月ほどですので、サンプルコード
Dependency Injectionを「依存性の注入」と訳すのは非常に悪い誤訳 - little hands' lab
Dependency Injectionとは Dependency Injectionを日本語でなんと訳しますか？ 大体「依存性の注入」と訳されることが多いですよね。 確かに直訳するとその通りなのですが、実際に行っていることを表していない、非常にミスリーディングな誤訳だと思います。 依存性を注入する、と言われると、まるで新しい依存性が増えるような印象を受けますが、実際はそうではありません。 googleの言語設定を英語にして検索してみると、英語版Wikipediaがトップで出てきて以下のように説明されています。 In software engineering, dependency injection is a technique whereby one object (or static method) supplies the dependencies of another objec
JavaScriptで大量のオブジェクトの当たり判定を効率的にとる - Subterranean Flower Blog
ゲームなどのコンテンツにおいて、「当たり判定」から逃れることはできません。オブジェクトとオブジェクトが衝突したかどうかという判定は、インタラクティブコンテンツにおいて最も重要な部分になるからです。 当たり判定の実装自体は難しくありません。ですが、素朴な実装ですと、対象となるオブジェクトが大量である場合に、十分なパフォーマンスが出ません。これはオブジェクトの多い、現代的なゲームでしたり、弾幕シューティングなどを作るときに大きな障害となります。 この記事では、大量のオブジェクトの当たり判定を処理する、効率的な方法について紹介します。 まずは素朴に実装してみる 当たり判定の処理を語るには、ある程度ゲームの骨組みのようなものが必要になってきます。もちろんクラスなどを使わないベタ書きでもよいのですが、大変読みにくくなってしまいます。ですので、今回は、まず簡易的なゲームエンジンのようなものを作って、そ
第3回 -ドメイン駆動設計のための オブジェクト指向プログラミング ハンズオン"に参加してきた！ - desi-gneer(designer_engineer)
今回はasoviewさんが主催された "ドメイン駆動設計のための オブジェクト指向プログラミング ハンズオン"勉強会に参加してきました。 asoview!（アソビュー）｜日本最大の遊びのマーケットプレイス まえがき 最近になって、また日に日にDDDの話題を見る機会が多くなってきていますね。そんな中、今回はasoviewさんが主催された勉強会に参加してきました。 本勉強会は1回2時間の勉強会を計3回実施するという、なかなか骨太な勉強会です。 (諸事情により、2回目は参加することが出来ませんでしたが…) これくらい時間をかけて行う勉強会はそう多くありませんが、 DDDを扱うにはこれくらい時間をかけて勉強会をするべきだとも思いました。 短い勉強会・発表だと、DDDの中で自分が気になっている箇所が取り扱われないこともよくありますし。 また、社内向けの勉強会を今回このように一般公開するという取り組み
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？
Eric Evans氏: ドメイン駆動設計は、以前より以上に妥当性を獲得している