Note: This website has been deprecated and is no longer maintained. Injecting Roles into objects in Ruby has been a hot topic in the DCI community. What's the correct approach when augmenting an object at runtime? I want to explore some techniques around getting objects to behave properly. Jim Coplien, a huge proponent behind the DCI architecture, makes a great point: “There are a million ways to
Note: This website has been deprecated and is no longer maintained. Many articles found in the Ruby community largely oversimplify the use of DCI. These articles, including my own, highlight how DCI injects Roles into objects at runtime, the essence of the DCI architecture. Many posts regard DCI in the following way: class User; end # Data module Runner # Role def run ... end end user = User.new #
DCI Example: Dijkstra #!/usr/bin/env ruby # Example in Ruby -- Dijkstra's algorithm in DCI # Modified and simplified for a Manhattan geometry with 8 roles # # # # Demonstrates an example where: # # - objects of class Node play several roles simultaneously # (albeit spread across Contexts: a Node can # play the CurrentIntersection in one Context and an Eastern or # Southern Neighbor in another) # -
“I always get so frustrated trying to dig through a project new or old, and trying to trace the flow of execution and how things fit together...” You can't afford complicated code. Writing small and easily testable methods can certainly clean things up, but as your application grows your classes start to know too much. Large classes means a large cognitive overhead for understanding how things wor
If you've read my previous article on the tip of the iceberg with DCI then you might be curious to find out more about it. You read a very simple example that was only used to make a point. But for sure, you're left wondering a bit: Why not make some other class to manage this if we want to separate functionality? Is this at odds with the program's "connascence" And another good question came up i
You've got a few Rails applications under your belt, perhaps several. But something is wrong. As you go, your development slows and your classes become bloated and harder to understand. Keep your program simple While you're doing your best to follow the concept of keeping your controllers skinny and your models fat, your models are getting really fat. The answer is simple: cut the fat. Your models
第12回G*ワークショップにて行った講演のスライドと発表原稿 はじめに 11/9にJGGUG様主催にて第12回G*ワークショップが開催されました。そこで、「Model On Grails - DCIアーキテクチャへの道すじ-」と題しまして、DCIアーキテクチャについて講演させて頂きましたので、その際のスライドと発表原稿を公開します。 スライドはこちら アジェンダは以下の通りです。 導入 先駆者たちが遺したもの オブジェクト指向の死角 DCIアーキテクチャ サンプル 導入 今回のテーマは「DCIアーキテクチャ」です。日本では、2010年の1月にJames O. Coplien氏が来日して講演したことで知られるようになりました。Googleグループのメーリングリストを見る限りは未だ黎明期にありますが、何か大きく化けそうな気配を漂わせていると言えるのではないでしょうか。 このDCIアーキテクチャ
● DCIが面白い件 DCI凄い！ヤバイ！ 「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」(翻訳) http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 前に読んだときは難しすぎて(長すぎて)途中で挫折したけど、今改めて読んだらDCIは凄いと気付いた。以下、まとめ。 今回、内容理解の決め手となったのは「前半部分を読まない」ことだった。 そんな無謀な読み方(読んでないのだけれど)をした私の理解なので、 もちろん間違いはあるはず。 という前提で、 ツッコミを入れる気満々なテンションでどうぞ。 古来からプログラムの中心は＜データ＞であった なぜなら、それが設計の中で一番変化しにくい要素(箇所)であるから そして、＜データ構造＞とそれに対する＜処理＞の2つで考えるようになった (手続き型
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。（原文公開日：2009年3月20日） 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
先日アレグザンダー祭りに行って色々感銘を受けたのですが、いまさら感想を書くよりはコードを書いた方が良いよねと思いました*1。以下はDCIアーキテクチャをJavaで実装したメモです。まだ聞きかじりなので間違いもあるかも。 といっても、元ネタはあるので、写経に近いですね。 http://www.markn.org/blog/2009/06/dci-on-scala.html (Scalaによる実装) http://www.jroller.com/sebastianKuebeck/entry/object_oriented_programming_2_0 (←こちらの例は余りに無駄な実装が多すぎる。。) 概要 DCIの例題によく出てくる銀行の送金処理を考えて見ます。この例って実は全然リアルじゃないんだけど、まあわかりやすいですよね。。 結論からいうと、Taitsもmixinも無いJavaでDCI
Takuto Wada @t_wada "Object Oriented is about end-users' mental model. Not (only?) about coupling, cohesion, and polymorphism" - Jim Coplien #dciwaseda Takuto Wada @t_wada "Agile is about doing then fixing. Doing, fixing, ... there is NO thinking in agile" #dciwaseda
Object-oriented programming was supposed to unify the perspectives of the programmer and the end user in computer code: a boon both to usability and program comprehension. While objects capture structure well, they fail to capture system action. DCI is a vision to capture the end user cognitive model of roles and interactions between them. Objects are principally about people and their mental mode
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
