2ヶ月くらい前に俺「来週ご飯食べいかない?」女「今忙しいし11月とかになるかも、行けそうな日あったら言うね」 2週間くらい前に女「ごめん11月無理みたい、12月なら大丈夫かもしれないし空いてる日あれば誘うよ」俺「わかった」 昨日俺「無理だったら前日キャンセルとかでもいいし日にちだけ決めない?」女「できたらいいんだけどドタキャンしたら悪いしな〜」 普通に喋ったりたまにLINEするくらいの中なんだけど、そろそろウンザリしてきた。ツイートする
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
Go使いたくなる理由の一つに、マルチスレッドプログラミング的なものを高速な言語で安全に実装したいというのがある。Goにおいてそれを支えるのが、自前で実装した軽量スレッドといえるgoルーチンと、mutexなどのロックの代わりに使えるChannelという概念だ。 実際に実装するときに、Goルーチンは難しくないが、Channelを使うのは割と知識と経験が必要なのでここでは、Channelについてすこし詳しく書いてみる。 Message Passing まずは理論から。 Goのチャネルなどのロックを使わない方法の並行処理はMessage Passingと呼ばれている。 以下の英語版Wikipediaにあるように数学的な理論にもなっているしっかりした枠組み。 ErlangのActor Modelなどもこの仲間。GoのチャネルとActor Modelは、実は、同等の概念で表現方法が違うだけらしい。 (
C言語やJAVA言語を使う人から見て、VBAは無用の長物なのでしょうか? そう思った理由は、以前とあるSNSのコミュニティにて"MS Excel""MS Access"の話題でとある人の「VBAできるといいのかな?」と発言から「VBAの仕組みは~」や「こんなマクロを作ったことがある」と話している中で、ある方が 「そんなのC言語でやればいいじゃん」 という発言をされる方がいました。続けて他の方 「JAVAで作れば余裕だよ」 と別の方が発言されたことから私は 「確かにC言語やJAVAでも可能でしょうが、今はExcelやAccessで使うVBAの話ですよ」 と返しましたら 「VBAしか出来ない奴にロクな奴はいないよ」 や 「その程度で語らないでくれるかな?」 という発言が続き、私はその話題から離れました。 今の仕事も"MS Excel"や"MS Access"でVBAを用いますが、自分は「プログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く