DI(Dependency Injection)について

現場で使っていて、
最近新規参画したメンバーに教える機会があったので、
あらためて自分でも整理してみた。

ちなみに、自分が経験したことのあるDI方法（注入タイプといったりする）は
もっぱらインタフェースによる注入。
インタフェースを実装するクラスにアノテーションをつけたりして、
XMLやテストクラスで実行するクラスを指定している。

■使ってみてのメリット
・ソースをいじらずにモックを使用したい箇所や未実装の箇所をスタブに置き換えられる。

今のところ、なかなか深まっていない。。
もっと深い気はするんだけどなぁ。

ちなみに、いろいろな記事を読んでもなかなかしっくりこず、
一番しっくりきた記事はwikipediaだった。。
http://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E3%81%AE%E6%B3%A8%E5%85%A5

アプリ作ってます【1】。

アプリを作成しています。個人で。

「登山」のアプリです。
「登山者のサポートをする」アプリです。
「登山で困ることを解決する」アプリです。
「登山をもっと楽しくする」アプリです。

そのために実現したい機能は
・時刻表の提供
→山というと、さすがに駅から直結で行ける山は少なく、
　駅に着いてからバスを乗り継いで山塊近くのバス停まで
　帰りはまた別のバス停から。。というのが往々にしてあります。
　いや、たんに時刻表を調べて、印刷したりEverNoteにはったり、
　そのEverNoteを同期したり。。というのが面倒になっただけなんですが。
　でも時刻表を簡単に調査、検索できたらいいなと。
　（アプリではなくブラウザからでもアクセスできますが、近くのバス停って名前わからんし）

・おススメスケジュールの提供
→実際に自分が歩いたコースや他のお勧めコースを掲載し、
　初めての人や歩いたことがないコースを歩くための参考になれば
　（地図もつけれればいいんだけど、開発パワーが。。）

・タ○ンページ
→単純に、関連する施設、緊急用連絡先をまとめておければと思いまして。
　あとはおいしい飲食店のTELやURL、小ネタなどを知れれば。

コンセプトとして、こういう方向目指したいというのはあるんですが、
どう実現するか、どう表現するかというのは本当に難しい。
デザインが苦手なのでなかなか魅力的なUIを作るのも難しい。
（助けてくれる方がいれば大歓迎ですが。。）

長文読んでくださりありがとうございます。

登山好きとして、登山のアプリを作り、
自分のアプリが自分の悩み、登山者の悩み、大きくは様々な課題に解決策を提供できる存在になればと思って、鋭意作成中です。

なにかご意見や「こういったことも困るんじゃないの？？」と言ったことが
言っていただければ幸いです。
よろしくお願いします。

【EffectiveJava[26]】

＜第 4 章 ジェネリックス＞
項目26： ジェネリック型を使用する

■著書からの要点抜粋
・ジェネリック型は、クライアントのコードでキャストが必要である型より、
　安全で使いやすいです。
・新たな型を設計するときには、クライアントのコードでキャストが不要であることを
　確認してください。それは、たいていは型をジェネリックにすることを意味しています。

■所感
ジェネリックを使うときにまずつまずいたりするが、
Objectをキャストして目的の型を取り出すコードよりははるかに使いやすい。
このあたりをもう少し上手に使えていければ。
型を保証する、ジェネリックの魅力の一つだなと思う。

Effective Java プログラミング言語ガイド

【EffectiveJava[25]】

＜第 4 章 ジェネリックス＞
項目25： 配列よりリストを選ぶ

■著書からの要点抜粋
・配列は実行時の型安全性を提供しますが、コンパイル時は型安全性は提供しません。
・ジェネリックスでは、それが逆になっています。

■所感
ジェネリックスを使用した型の安全性を保証するためには、
型を定義できるジェネリックスを選んだほうが
コンパイル時にエラーを発見できるので便利というのは納得。
基本的に配列よりはList派だなぁ。

Effective Java プログラミング言語ガイド

今週のお題「オススメの気分転換法」

今週のお題「オススメの気分転換法」

個人的におススメなのはランニング。
だいたい週末まで働くとヘロヘロに疲れていて、、、
土曜日は午前中ぐったり（最近はそうなっています。。。）

でも、夕方にあえてランニングをすると、
疲れが逆に発散、気分もスッキリして、
来週からの仕事にまたリフレッシュして臨めます＾＾

【EffectiveJava[24]】

＜第 4 章 ジェネリックス＞
項目24： 無検査警告を取り除く

■著書からの要点抜粋
①取り除くことが可能なすべての無検査警告を取り除いてください。
②警告を取り除くことができなくて、
　警告を起こしているコードが型安全だと明確に示すことができれば、
　その時に@SuppressWarnings("unchecked")アノテーションで警告を抑制してください。
③SuppressWarningsアノテーションを、できる限り最小のスコープに対して使用してください。
④@SuppressWarnings("unchecked")アノテーションを使用するときには、
　そうするのが安全である理由を述べるコメントを必ず追加してください。

■所感
チェックスタイルなどに任せれば、①・②まではできるし、
自分で疑えば③まではできる。
でも、④をするのはレベルが高い。。
そもそも①、②を任せててコーディングしているだけでは
理由づけなんてできないもんなぁ。。

Effective Java プログラミング言語ガイド

【EffectiveJava[23]】

＜第 4 章 ジェネリックス＞
項目23： 新たなコードで原型を使用しない

■著書からの要点抜粋
・原型を使用すると、ジェネリックスの安全性と表現力のすべてを失うことになります。

■所感
ジェネリックスの用途自体は理解できているけども、
この章の内容をうまく説明するのは難しい。。
ポイントはListと書くよりもList（要素の型を指定する）と書こうということかな。
大概はチェックスタイルなどで警告を出すし、
大概の仕事ではチェックスタイルでひっかかる場合はコードの修正を求められるし。
上記要点だけであるならばそれほど難しいものではない認識。

Effective Java プログラミング言語ガイド