iOS13未満での実装方法の詳細については以下の記事で説明しています。 Qiita - iOSとコードベースレイアウト 勿論、プロパティインジェクションならばiOS12以下でもStoryboardで定義したUIViewControllerで可能ですが、initializerでのDIをする設計にすることで以下の恩恵が得られます。 DIする値をプロパティで保持する場合に、varでなくletで定義できるのでより安全 DIする値をプロパティで保持する場合に、Optional型でなく非Optional型で定義できるので無駄なUnwrapが不要 UIViewControllerの生成を行うために、必ずDIが必要になるので、プロパティインジェクションのように設定忘れが起こり得ない iOS13でStoryboardでイニシャライザでDIする iOS13では地味にこんなAPIが加わっています。 instan
About the content 2017年3月のtry! Swift Tokyoの講演です。映像はRealmによって撮影・録音され、主催者の許可を得て公開しています。 モックを使うことでプロダクション環境のデータを壊すことなく素早くテストを書くことができます。OCMockを使わずに、あまり手間をかけずにモックを書くにはどうしたらいいでしょうか。try! Swiftで話されたこの講演で、Veronica RayはSwiftにおける実践的でメンテナンスしやすくシンプルなモックを書く方法を示します。 テストは書きたいけれど… (0:11) …プロダクション環境のデータを壊してしまったり、テストが遅かったりするのは困ります。こちらはとても簡単なNSURLsessionを使う例です。みなさんのコードにもあるかと思います。もし実際の通信と同じリクエストを使ってテストをしたとすると、テストはすごく遅
The Koin framework has been started a while now (remember when I published its first lines in “Better dependency injection for Android”). I daily use Koin on several apps in production & begin to have some encouraging feedback (article updated with Koin version 0.9.2). To show you how it can help you and save your time, let’s take a real app example — The TodoApp from Google Blueprint Architecture
Sep 18, 2017 このところかなり忙しく、iOSDCでちゃんとしたことを話せるのか不安でしたが、なんとか無事に終わりました。あまり会場を盛り上げることができず、後半はしどろもどろで死にたくなりましたが、面白かったと言ってくれた方もそれなりにいたので少し安心しました。 DIは今回の話以外にも色々なことに挑戦していて、最初はデフォルト引数を使った手動のinitializer injectionから始めて、SwinjectやCleanseなどのライブラリを試してみたり、Cake Patternを模倣してみたりしていました。それらを通じて、自分が求めるDIのプラクティスは 依存の宣言とインスタンスの取得のためのコードが単純かつ十分に少ない コンパイル時に依存関係の解決が検証される というものだとわかりました。もしも「dependencyの宣言さえしておけば、あとはコンパイルエラーを直してい
iOSオールスターズ2 https://eventdots.jp/event/602872
DIコンテナ使ってるけど、アノテーションってなんなの！って聞かれて、作ってみたらわかるよと答えてみたので、自分でも作ってみました。 よくわかった。 「DIコンテナ使うと何がいいの？」ということも、作ってみるとわかります。あと「DIって何がいいの？」に関しては、「DIはちょっとコードを書くのが楽になるだけで、それだけあっても仕方ない、大事なのはコンテナ」と答えるようにしてますが、コード比率からもそれがよくわかります。 続編としてWebフレームワークも作っているので参考まで。 作って理解するWebフレームワーク - きしだのHatena まずはコンテナを作る とりあえず1ソースの状態で。 こんな感じで、管理する型を登録できるようにします。 static Map<String, Class> types = new HashMap<>(); static void register(String
Contexts and Dependency Injection（CDI）入門 1. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.1WebLogic Server 勉強会Context and Dependency Injection(CDI)入門2013年 6月20日日本オラクル株式会社Fusion Middleware事業統括本部 松林晶 2. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.2Program Agenda Context and Dependency Injection(CDI)– CDIとは– CDI 1.1 New Feature(Java EE 7) 3. Copyright ©
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
こんにちは、馬場です。 唐突ですが、現在Play! + Scalaで開発しています。 それまではほとんどJava (たまにRuby/Rails)で作っていたので、本格的にサービスをScalaで作るのは初めて。 慣れないながらもすごく楽しくやっていましたが、プロジェクト開始早々でてきた不満。それは 「DIしたい…」 なぜなら「テストが面倒だから」。 データベースアクセス、webapiの呼び出し、メール送信と外部リソースへアクセスする処理のオンパレード。テストのたびに実行していたらスローテストに陥ることは目に見えています。リファクタリング／パフォーマンスチューニング／ライブラリのアップデートに耐えるためにも、ここはぜひともDIを導入しておきたい。 というわけで、Scala アプリケーションへのDIの導入体験を紹介したいと思います。 Java で DI まずはJavaのDIコンテナSpri
Seasar、SpringなどのDIコンテナを使っていると、ドメイン層の実装はデータ（Entity／Dto）と振る舞い（Service／Logic）に分ける、いわゆるトランザクションスクリプトのスタイルになりがちだ（参照(1)、(2)）。理由は、1つにはドメインモデルの設計／実装そのものの敷居が高いこともあるが、そのハードルを乗り越えても、DIコンテナそのものがドメインモデルと馴染みにくい側面があるからだと思われる。 DIコンテナはエンティティやDTOにDIできない その側面とは、次の通り。DIコンテナは設計思想からしてファクトリの役目をするものであるため、DIコンテナを使う場合、インスタンスの生成は基本的にDIコンテナが担当することになり、コンポーネントに必要なオブジェクトはすべてDIで渡されるような設計に誘導されてしまう DIを使ったWebアプリケーションのアーキテクチャは、まずリクエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
