久しぶりに DCI がらみで BabyIDE にヒントがあるかもしれないな…と思われる話題に接したのを機に、以前遊んでみた BabyIDE のその後を調べてみたところ、引き続き Squeak3.10.2 上で開発が続けられている BabyIDE-2018.07.31.ZIP というのを発見して驚きました（氏は御年88歳！）。同時に、それよりちょっとバージョンは古そうですが、プラットフォームとしては比較的最近の Squeak4.5 にインストールして使えそうな SqueakMap パッケージ BabyIdeAllInOne の存在を知ることもできたので、今回はこれで遊んでみることにしました。 DCI と BabyIDE については過去の記事を参考にしてください。 DCI パラダイムの提唱者、Reenskaug 氏の BabyIDE で遊ぶ DCI パラダイムの提唱者、Reenskaug 氏の
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
PHP Advent Calendar 2013 - 6日目 昨日は@fivestrさんのComposerを使った簡単Travis CI設定でした。 TL;DR オブジェクト指向/MVCでうまく捉えきれていなかったものは何なのか？MVCから続くソフトウェアアーキテクチャーの「その先」は何なのか？Reenskaug博士を知っていますか？ WikipediaによればReenskaug博士は1930年生まれ。MVCという概念が世の中に送り出された論文『MODELS - VIEWS - CONTROLLERS (pdf)』は1979年ですから、49歳の時ということになります。1960年からソフトウェアを書き始め、1973年からオブジェクト指向でソフトウェアを開発しており、現在でも現役でソフトウェアの世界にいらっしゃいます（ex 2009年の講演）。「プログラマ歴42年 (* Clean Coder
DCIアーキテクチャを用いて、割り勘の計算を行うWebアプリケーションを実装する。 導入 前回のエントリでは、DCIアーキテクチャの思想に基づき、試験的にドメインレイヤを実装しました。今回からはその発展編として、DCIアーキテクチャによるWebアプリケーションについて、数回に渡り検討していきます。言語はScala、WebフレームワークとしてはWicketを使用します。なお、データは今のところメモリに保持することとし、永続化層の実装については後日検討することにします。初回の今回はドメイン層をターゲットとして設計について考えていきます。 割り勘アプリケーション 要件 これから実装していくのは「割り勘アプリケーション」です。前回でも使用していたSharePieの概念を身近な形で引き継いだものですね。使用される状況は以下のようなものを想定しています。 飲み会の清算は等分ではなく、役職に応じて「傾斜
Trygve Reenskaug氏とJames O. Coplien氏らが提唱する「DCIアーキテクチャ」について、id:digitalsoulさんが論文を翻訳してくださり、またその解説とサンプル実装(groovy, scala)を示してくださっており、読んでみたところ、大変興味深いので理解した限りを書いてみます。 おじさん登場 たとえば、あるおじさんがいたとします。 このおじさんは、白いスーツ、グラデーションの入ったサングラスと金ぴかのネックレスをつけて新宿歌舞伎町に出かけ「やくざ」として振るまいます。とおりかかったお兄さんがそのおじさんに出会い、目が合ってしまい、因縁を付けられ、お金を巻き上げられてしまいます。 さて、おじさんは家に帰ります。実は、このおじさんは家では良いお父さんとして振る舞います。赤ちゃんはこのおじさんの目を見て笑いかけます。おじさんは相好を崩し、オーよしよし。 さて
NOTE: 最下部に追記があります。 よく言われる話として、 DCI なんて実装が面倒な上に夢の実装の話をしており、現実解としては Service クラスを用いて実装すればシンプルな実装になるのだから、そういったものは必要ないのだ、というご意見への返答です。 こういった批判の文脈の際、 Service クラスというのがどこの Service クラスを指しているのか、が問題なのですが、 DDD における Service ではないように思えるので、おそらく PofEAA などで語られる Service Layer などを指していると思われます(違うならそう言ってください)。 PofEAA における Service Layer(以後、 Service と呼ぶものはこの PofEAA における Service です)はドメインオブジェクトからアプリケーションロジックを切り離すことを主目的としていま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
