CM Developers.IO 2016 in Osaka 二週間以上も前のことになりますが、Develpers IO in Osaka 2016 で ゲンバのクリーンアーキテクチャと題して、クリーンアーキテクチャ を用いて、現場でモバイルバックエンドAPIをどのように開発しているかについて発表しました。 発表スライド Content of session 当日発表したセッションの概要です。 クリーンアーキテクチャとは Clean codeの著者であるRovert C.Martin氏が提案したアーキテクチャです。外界（API I/F, DB Schema, 外部システム）に依存しないコードをどのように記述し、パッケージ等を整理するかについて明確な方針を与えます。 外部に依存しないコードを記述するために DI(依存性注入) と DIP(依存性反転の原則)を用いて外部に依存するコードの抽象を
Dependency Injectionとはコンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである ってwikipedia先生が言ってました。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita を読んでいろいろ考えたので、なんで今さらって感じのことを書きます。 ScalaでDIというとDIコンテナとかCake PatternとかReader Monadとかって話になっちゃうんですが、これらはいかにかっこよくDIするかの話であって、別にこういった道具やパターンを使わなくてもDIは可能という話です。 Constructor Injection 簡単な例で考えます。今ここにUserRepositoryにべったり依存し
3.4 Dependencies bean間の依存関係の定義について。なんか書いてあったけど忘れたので省略。この節は長いな…。 3.4.1 Dependency injection SpringのDIには、コンストラクタインジェクションと、セッターインジェクションがある。 3.4.1.1 Constructor-based dependency injection コンストラクタによるＤＩについて。基本形。 基本型など型が不明瞭な場合のシンタックスその１ 基本型など型が不明瞭な場合のシンタックスその２。引数順を指定する。 基本型など型が不明瞭な場合のシンタックスその３ （debugオプションつきか、@ConstructorPropertiesをつける必要あり。引数名から特定。） 3.4.1.2 Setter-based dependency injection setterで指定。例はあと
etc9さんの"心地良すぎるモックライブラリ Mockito"がとても勉強になったので、似たような形式でGuiceの紹介をしてみます。 Dependency Injection きちんと勉強したわけではないので間違っていたらごめんなさい。Dependency Injection (DI)はユニットテストを書きやすくするためのクラスの書き方の一つです。クラスAが内部でクラスBを使うとき、Aの中でBをnewする代わりに、AのコンストラクタやsetterでBのインスタンスを外部から渡せるしておきます。こうしておくとAのユニットテストを書くとき、Bの動作を真似るモックオブジェクトを渡すことで、Bの中身を考えずにAをのテストを書けるようになります。これはAとBの動作を同時に考えてテストを書くよりずっと楽だと思います。依存性注入とかレポジトリパターンとも呼ばれているっぽいです。 GuiceはDIの補助
こんにちは、馬場です。 前回はScalaのDIのパターンとしては最も有名なCake Patternを紹介しました。今回はDIの他のパターンも紹介したいと思います。 Twitter でのScala DI さて、少し前にTwitter がScala のベストプラクティスをgithub上に公開しました。DIについては、以下のように言っていますね（かなり意訳です）。 Scala にmixinの仕組みを導入したのは、伝統的なDIの手法をやめたかったからだと思う。新方式の最たるものが「Cake pattern」だろう。 (略） けど、Scalaを利用するだけで、古典的DI手法の問題点はだいたい解決できると感じる。(略）だから、私たちはあまり継承せずに構造化しようと決めた。その方がモジュール性が高くテストしやすいプログラムができると思うから。 「伝統的なDIの手法」というのは、Springと同じよう
こんにちは、馬場です。 唐突ですが、現在Play! + Scalaで開発しています。 それまではほとんどJava (たまにRuby/Rails)で作っていたので、本格的にサービスをScalaで作るのは初めて。 慣れないながらもすごく楽しくやっていましたが、プロジェクト開始早々でてきた不満。それは 「DIしたい…」 なぜなら「テストが面倒だから」。 データベースアクセス、webapiの呼び出し、メール送信と外部リソースへアクセスする処理のオンパレード。テストのたびに実行していたらスローテストに陥ることは目に見えています。リファクタリング／パフォーマンスチューニング／ライブラリのアップデートに耐えるためにも、ここはぜひともDIを導入しておきたい。 というわけで、Scala アプリケーションへのDIの導入体験を紹介したいと思います。 Java で DI まずはJavaのDIコンテナSpri
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
