タグ

dciに関するpeketaminのブックマーク (9)

  • 今年も1月終わったし DCI の話しようか - Qiita

    いままで色々 Rails 向けに DCI を実現する gem を作ってきたわけですが(Dicer / BluePrint)、今年もまた新しく考えなおして Rails 向けに DCI を実現する gem を書きました。毎年毎年ほんとよくやりますね。 今年は何気なく作り続けて、いままで活用されていなかった uninclude という gem をついに使って DCI をやってみました。 uninclude にてついては特に解説することもないというか、名は体を表すということで『#unextend や #uninclude を Ruby で使えるようになる』という gem です。Refinements などでも実現可能なのですが、Refinements はファイルごとだったりでスコープがわかりづらくなるので使っていません。 RockMotive 2015年の DCI on Ruby は RockMo

    今年も1月終わったし DCI の話しようか - Qiita
  • PHP5.4 で実装された trait のまとめと実際の利用例|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

    PHP5.4 で実装された trait のまとめと実際の利用例 弊社技術ブログへお越しのみなさま、こんにちは。今年度入社の新人、 YamaYuski です。 先日、社内勉強会にて「traitを使って楽したい話」という演目で簡単に trait について発表しました。 trait が実装された PHP5.4 は2年も前にリリースされたものなので、何故今更、という話になると思います。 しかし、ネット上(特に日語圏)においての trait の記事はまだまだ少なく、具体例を探すのも大変だったので、「もしかして trait はあまり浸透していないんじゃないか?」と考え、 trait の有用性を世に広めるためにこの記事を作り始めました。 今回は、初心者ながら個人的に調べたり考えたりしたことを、 trait とはなにか trait の実装方法と利用方法 どのようなケースで実装するか 実装時の小ネタ の4

    PHP5.4 で実装された trait のまとめと実際の利用例|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
  • ssig33.com - DHH についての見解

    DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話

  • http://www.zusaar.com/event/5037004

  • MVCの流れを簡単にまとめてみる - Qiita [キータ]

    理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア

    MVCの流れを簡単にまとめてみる - Qiita [キータ]
  • ドメインを巡るお話 | Uzzu::Blog

    Jan 4 2014Tags: dci ddd 昨年末にだらだらDCIに関する自分の考えを整理したくて身内で話していて、 結論としては「DDDとDCIどちらもメンタルモデルに近づけるために機能してる点は変わらない。その先DDDあるいはDCIをフレームワークにするか、あるいは一部に取り入れるのか、そこは取組むドメインによって取捨選択だよね」というところに落ち着いたのだけれど、勿体無い内容な気がするので改めてブログに書くことにする。 DDD脳から見たDCIの考察 DCIはFATなドメインモデルに対するアプローチというよりは、シナリオを明確にするためのアプローチなのかなと思う。 DDDを実践するような複雑な問題に直面した時、ドメインモデルは山のように増える。より知識を噛み砕いてドメインモデルにしたほうがより上層のロジックが簡潔になるので積極的にドメインモデルに落とし込む方がよく、結果として、シナ

  • Fatty - Laravel Bundles

  • トレイトにおける、メソッドコンフリクト時の対処のしかた - Smalltalkのtは小文字です

    多重継承機構を利用する際の問題としてよく取りざたされる「メソッド名のコンフリクト(衝突)」ですが、Squeak Smalltalk のトレイト機構(Traits)では、同種のミックスイン機構の場合と異なり、その対処はユーザーに委ねられます。 たとえば、いずれもメソッド #m1 と #m2 を持つ T1 と T2 というトレイト、両者を同時に use するクラス C があったとき、 Trait named: #T1 uses: {} T1 >> m1 ^'T1>>#m2' T1 >> m2 ^'T1>>#m2' Trait named: #T2 uses: {} T2 >> m1 ^'T2>>#m1' T2 >> m2 ^'T2>>#m2' Object subclass: #C uses: T1 + T2 トレイト機構は、C >> #m1(および #m2) に対して、 C >> m1 se

    トレイトにおける、メソッドコンフリクト時の対処のしかた - Smalltalkのtは小文字です
  • Scalaのトレイトは実はトレイトじゃなくただのミクスイン - Smalltalkのtは小文字です

    タイトルは釣りです。 まずおおざっぱに用語の整理をさせていただくと、ここで「トレイト」は、シェルリ(Nathanael Schärli)らが2002年頃に発表したTraitsやそれ用のエンティティ(trait)を指し、「ミクスイン(Mixin, mixin)」は従来からある実装の多重継承方法のひとつ、具体的には継承機構を使ってメソッドを定義したクラス様エンティティ(クラスでも構わない)を継承パスに差し込むことで対象となるクラスにメソッドを追加する機構(特別な機構を要しないときは単なるクラスの運用方法)、そのときに用いるクラスあるいはクラス様エンティティ(例えばRubyならモジュールとか)を指すことにします。 トレイトやその機構について説明すべきことはいろいろありそうですが、詳しくはシェルリらの論文(Traits: Composable Units of Behaviour など)を読んでい

    Scalaのトレイトは実はトレイトじゃなくただのミクスイン - Smalltalkのtは小文字です
  • 1