日々常々

ふつうのプログラマがあたりまえにしたいこと。

「現場で役立つシステム設計の原則」の目次流し

本日発売された @masuda220 さんの「現場で役立つシステム設計の原則」が気になってる方へ。

紙の本。

こっちはkindle

まだ全部読めてないけれど、精読するといつ読み終わるかわからない・・・。 なので、まったく読んでない気分になって目次ベースで紹介してみます。 どう言うことが書いてそうかの参考にはなるかなと。

しかしこの内容、よくこのサイズの本で、それほど小さくない字なのに入りましたね。要約力のなせる技なんでしょうか。

目次流し: 期待とつまみ食い

目次をさらっと読んで、こんなこと書いてるのかなーって妄想を交えて書き連ねます。たまに実際開いて。 なお、 「太文字のカギカッコ」 は目次からの引用です。

Chapter1 小さくまとめてわかりやすくする

ソフトウェアはソフトなのに変更が大変になるのはなぜだろう。 これには大きくしてしまった時点で負けと言う原則がある。 大きくせざるをえないものがないとは言わないけれど、小さくする、小さく保つ努力を怠っていい理由にはならない。

このChapterでは小さくあるためにどのようにするかが書かれていそうな雰囲気。 難しい言葉で言えば高凝集で疎結合なのだが、抽象的な話に逸れがちなテーマ。 これに対してメソッドやクラスを作成する上での一般指針や、ファーストクラスコレクションをあげているので、抽象ではなく具象で語っているのだろう。

Chapter2 場合分けのロジックを整理する

組み合わせられるように作成できるのはソフトウェアの強みではある。 一方で簡単に組み合わせ爆発を起こしてしまい、気づいたら制御できなくなっているものである。 C2カバレッジが現実的でないと言われたりする話もある。

このChapterでは、組み合わせを発生させないためにできることを詰め込んでいるようだ。 そんな何でもかんでも組み合わせる必要はない、こうすれば余計な複雑性を放置せず済む、と区分や種別の引力に対峙している。 また、本書はJavaを使っているため、強力な機能であるenumの実践も記述されている。 私自身、増田さんと仕事をさせていただいた時に「enumをそう使えばいいのか!」とショックを受けた。 その内容はわずか2ページにエッセンスが詰め込まれているのだが、このChapterだけでなく前Chapterも理解して身についていなければ、単に「ふーん」で読み流してしまう。

Chapter3 業務ロジックをわかりやすく整理する

神クラスが生まれるのはなぜだろう。 他言語にあるプロパティ構文やLombokが欲しくなるような、getter/setterだけを持っているクラスに何の価値があるだろう。 余計な複雑性を持ち込んでいるんじゃないか。 データとロジックが同じ場所にあることがカプセル化だったんじゃないか。 あれはただの教科書的なもので、実務では使えない机上の空論なんだろうか。

・・・なんて話に真っ向勝負を挑んでいるのが、このChapterの見出しを眺めた印象である。 重要なのは、ここで記載されていることが全て実際のシステムからの知見であること。 また、海の向こうの関わりが少ないものではなく、日本のシステム開発で実践されたことであることかもしれない。 文化が違うから実現できるんだ、ウチではそういうのはできないんだ、なんて言い訳をいつまでも続けるのは難しい気がする。

Chapter4 ドメインモデルの考え方で設計する

増田亨と言えばDDDの人と認識されている方も結構いるはず。 DDDは「エリック・エヴァンスドメイン駆動設計」が有名で、本書が登場してからよく聞くようになった言葉である。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

とは言え「DDD=エリック・エヴァンスドメイン駆動設計」でもなく、増田さんは増田さんのDDDを実践していると思っている。 つまるところ、このChapterは「増田亨のドメイン駆動設計」なんだろうなーと。

見出しを眺めると、エヴァンスの言葉はほとんど使われておらず、むしろ「コト」などの聞き慣れた言葉が使われている。 どう解釈するか、などに悩まずに素直に内容と向き合えるのじゃないかなと。

そして教科書的に済まないのが本書の特徴。 前半で一通り説明したのち、最後 「業務の理解がドメインモデルを洗練させる」 では 「形式的な資料はかえって危険」「言葉のあいまいさを具体的にする工夫」 など、現場で向き合ったこともあります。 現在進行形で取っ組み合いしてるところなので重点的に読みたい。

Chapter5 アプリケーションの機能を組み立てる

サービスクラスを作ると、ドメインモデルの責務がサービス側にうっかり漏れ出して、ドメインモデルが空洞化するなんて話はよく聞くところで。 また、業務システムはデータベースありきな文化も強くあります。 これらの慣習的な作り方の引力への抗い方について書かれてそうな感じがします。

「初期のドメインモデルは力不足」 と言うまぎれもない事実を事実として認め、それからどうするか。 決して"最初から完璧なドメインモデルを作ろう"ではないはず。

Chapter6 データベースの設計とドメインオブジェクト

データベースに関わるよくある問題と、テーブル設計の一般則、そして工夫と言う感じで書かれているようだ。 問題点などはSQLアンチパターンとも絡むのかな(参考書籍にもあげられてるし)

SQLアンチパターン

SQLアンチパターン

「参照をわかりやすくする工夫」 のところでは、当然のようにイミュータブルデータモデルや、結果整合性が書かれている感じがする。 そしてChapter5でデータベースに引っ張られないようにと説明していたはずが、ここで 「オブジェクトとテーブルは似てくる」 と言われてしまい、え?となっているところに 「オブジェクトはオブジェクトらしく、テーブルはテーブルらしく」 と続けてくるのは面白い。

Chapter7 画面とドメインオブジェクトの設計を連動させる

DDDで捉えたつもりのドメインモデルと、画面の要件がズレていることは珍しくない。 そこには色々な関心ごとが混じり合っているから。 画面向けのドメインと実際のドメインが別にあり、それらが複雑に絡み合っているんじゃないか、なんて考えたこともあるのだけれど、そんなことをしているとシステムを作るのに莫大なコストがかかることになってしまうので、違うんじゃないかなーとか思ってた。

このChapterでは 「画面とドメインオブジェクトと連動させる」 として、画面都合のロジックをどのようにしてドメインオブジェクトに記述しつつ、ドメインオブジェクトの独立性を維持するのかが書かれてそう。 なおWebアプリケーションの画面なのでHTMLが前提になってます。

Chapter8 アプリケーション間の連携

流行り?のマイクロサービス的な話がはいってるのかなーと眺めてみたけれど、そのような記述はないです。 ここでの連携は素直にアプリケーション間の連携で、対象はファイル転送、データベース共有、Web API、(非同期)メッセージングを指しています。 その中でも特にWeb APIに重点が置かれているようで、7割くらいはWeb APIの話っぽい。

Chapter9 オブジェクト指向の開発のプロセス

ここで開発プロセスの話に飛ぶのか。 開発プロセスのソフトウェアに対する影響などの一般則から、 ソースコードを第一級のドキュメントとして活用する」 の転換。 そして 「更新すべきドキュメント」 として、現実で必要になるソースコード以外のドキュメントの話。 決してドキュメントは全て不要!なんて言ってないのがわかる。

なぜ開発プロセスの話になるんだろうと思ったので少し先読みしたところ、どうやらプロセスを変えないとオブジェクト指向の開発はできないようなことが書いてそう。 初期のドメインモデルが力不足なのだから、当然と言えば当然で、それを通すためにはプロセスも当然あったようにしないとね。

Chapter10 オブジェクト指向設計の学び方と教え方

リファクタリングオブジェクト指向エクササイズなどなどの話。 これだけで一冊書けるところですが、車輪の再発明ではなく、主に本の紹介で構成されてるChapterです。

全体通して

本を受け取った時は、あれ、本小さくね?軽くね??って思いました。 こうしていざ目次を見てみると、思った以上に広い。そして深い。びっくりした。

タイトルの「現場で役立つ」ですが、実際役立てるかは読んだ方ご自身の責務です。 あたりまえですが、読んでも使わないと役に立ちません。装備しないとダメとかそう言うやつです。

あと参考文献のページに書影入ってるのが地味にいいですね。

対象読者層

読みやすい文で、分量は多くなく、コードや図は多め。 そしてそれほど高くなく、このカバー範囲。

「システム設計の原則」と言うと身構えるかもしれないけれど、新人から少し脱したくらいから読んでもいいんじゃないかなと思います。 おそらく、難しくて全く理解できないなんてことにはならない。

一方、書いている内容の理解の仕方は、背景の知識の広さや深さで大きく変わる印象を受けました。 どのChapterをとっても、完全に理解していて何も得るものがない、なんてことはそう無いでしょう。

そのため、システムを開発するあらゆる方に読んで貰いたいと思いました。 現場でもこの本を読んでる前提で、どうしようって話ができると楽しそう。

読書会とかするといいんじゃないかなー

対象読者が幅広くて、コンテキストによって理解の仕方が変わりそうなので、持ち寄って「自分はこう読んだ」なんて話をすると面白いんじゃないかなーと。 と言うのも、平易な文でボリュームが少ないので、さらっと読んでしまおうと思えばそれで終われるんです。 でもそうしちゃうにはちょっともったいない感じもする。

ネタ: タイトルについて

「現場で役立つシステム設計の原則」なんですが、増田さんの会社名って「システム設計」なんですよね。。。 なので、会社名が他のだったら、 現場で役立つXXXの原則 (XXXは任意の会社名)となったのだろうか、とかなんとか。 いや、どうでもいいんですが。

"ふつうのJavaコーディング"を話しました

2017/5/20にあったJJUG CCC 2017 Springで登壇させていただきました。 8回目の参加です。

毎回パワーアップしているなーと言うのは前回のブログでも書きましたが、今回は目に見えて参加人数が増えたんだなーと体感しました。 入れないセッションもありましたし、懇親会も超満員でした。運営の皆様に本当に感謝です。 今後も楽しみにしています。

話したもの

ごくふつうの話、のつもり。ふつうって一体なんだとか思わなくはないですが、ただの枕詞なので意味はないです。

結局のところ九段に集約されるんですが、強い意思を持つには色々必要で、まあそんな感じです。

「coming soon」となっている61スライド目

先日(6/24)発売のWEB+DB PRESS Vol.99 で書いてます。

WEB+DB PRESS Vol.99

WEB+DB PRESS Vol.99

  • 作者: ?橋健一,谷口禎英,井本大登,山崎勝平,大和田純,内村元樹,坂東昌哉,平田敏之,牧大輔,板敷康洋,大?浩崇,穴井宏幸,原口宗悟,久田真寛,ふしはらかん,のざきひろふみ,うらがみ,ひげぽん,池田拓司,はまちや2,竹原,片田雄樹,渋江一晃,WEB+DB PRESS編集部編
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/06/24
  • メディア: 大型本
  • この商品を含むブログを見る

連載のJavaの新定石、第8回となる Optional/Stream適材適所 です。 内容が気になる方は、よろしくおねがいします!

Agile Japan 2017 京都サテライト おいでやす〜のメモ #AgileJapanKyoto

Agile Japan 2017 京都サテライト おいでやす〜 の参加/運営メモです。

「ブログを書く かつ 現場で実践するまでがAgile Japan 2017 京都サテライトです。」 って言われたので。

ちなみに元々は「ブログを書く または 現場で実践する」ってなってました。 「または」の場合、言語によっては前を評価すれば後ろは評価されないので、それはないでしょーって言ったら「かつ」になりました。 めんどくさい奴ですみません。あ、実践はしたのでブログ書いてます。

聞いたやつ

雑に書きます。

基調講演(動画)

前週の大阪サテライトと同じなので、内容については割愛。(ブログ書いてないけど)

大阪サテライトではスライドのズームとか開原さんが頑張ってらっしゃったなーと。 設備とかの関係でできなかったので、うん。 動画サテライトはスライドだけの動画がいいなと思いました。

メトリクスによる「見える化」のススメ: No 見える化、No 改善

タイムテーブルの都合で、前半1時間だけサポート?的に観戦。 チームで課題を出し合って、一つ課題を選択し、メトリクスを設定してみようってところまで。

想定課題だと難しいなと思うのがワークショップとしてのところ。 で、主眼であるメトリクスを出しているフェーズを見ていて思ったのは、メトリクスを挙げずに解決を考えちゃってたのが印象深かった。 みんなエンジニアだなーと。 メトリクスを設定する意義がぼやけていたような気が。

分析と創造は思考のスイッチが違う(後述の「みんなではじめるデザイン批評」より)ので、何をメトリクスとするかを分析しているフェーズで解決策を考えるのはあまりよろしくないよーな。 実際の打ち合わせでもあるあるで、おそらくファシリテーターが口出しする展開な気がします。

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

何を計測すればわかりそうかって想定してウォークスルーとかする感じかな。 思いつきの対応ではなくまず計測から入れってのはパフォーマンスチューニングでは鉄則の話。プロセスでもそうってことだろうか。面白い。 タイムテーブルの都合で、後半1時間は見れなかった。残念。。

リモートチームの道具箱

チームにおいて何を重視し、どの様なトレードオフを受け入れて試行錯誤しているかが印象深かった。 最低ラインに合わせているように見えるかもしれない、けれどチームにとってどうあるとよいのかに向き合って選択していってるのだろうなー。 話にあがってた道具をそのまま同じ様に使っても思う様に効果は出ないでしょうね。

アジャイルで缶詰? 〜ソフトウェア開発以外でのアジャイル活用事例〜

非常に魅力的で、缶詰が食べたくなりました。会場で即売会されたら多少高くても買ってた・・・。 ソフトウェア開発の文脈で得た「アジャイル」を非ソフトウェア開発への適用。 似た様な話はリーンスタートアップなどでもありますが、対象が缶詰という身近なもので具体例を挙げられるとイメージしやすいですね。

芯を通す開発を目指して ー アジャイル"ファン"が本気でアジャイル開発に取り組んだ2年間 ー

芯ってなんだよ、俺はこれを芯と捉えるよ、という話。 京アジャに参加し始め当時の私からすればエキスパートに見えていた彼。 まさかの「アジャイル"ファン"」カミングアウトですよ。まじかー、と。でも言われて見ればぴったりのネーミングですね。

他諸々気になるところはあったので今度話しましょーって声をかけた。どうなるかは知らない。

LT

酔っ払いのLT大会とはかくあるべしって感じでした。

永田さんのLTが強烈で、会場からの延長要請により2セット行われました。 色々と考えさせられる、というか終わった後少しお話させていただいて、思考整理してたらブレイクスルーがきたのでとても得した気分です。

運営的なのを含めた感想

色々と反省点が多かったです。 色々ってのは、打ち合わせにいけなかったり、当日集合時間に遅れたり、自分の役割把握してなかったり、ほんと色々。まあいいや。 ふりかえりしたけど、次改善するかは知らない。次ってなんだよだし。

参加された方々はもちろんですが、それ以上に日新システムズさんの方々が強力にバックアップしていただいたおかげで成立したと思います。 この場に書いても届かないでしょうが(届かなくていい)、ありがとうございます。

Java本格入門を読みました

ゴールデンウィークの間に圧倒的成長をしたい若手プログラマさんに丁度いいんじゃないでしょうか。

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

Java本格入門をせろさんからいただきました。

よかったところ

この本で特に読むべきところを挙げるならば、「筆者は」で始まる部分です。 Javaはエコシステムも含めて選択肢の多い世界のため、「どれを選べば良いかわからない」こともしばしばあります。 そのような問題に対して、経験をベースにどういう考えでどんな選択をしているかが書かれています。 こういうのを前面に押し出した書籍は希少かなと。 ここだけ抜き出してもすごく価値があります。目立つようにしててくれたらいいのに。

言語仕様等、事実の解説はどうしても不足しますが、それは仕方ないところ。 プログラミング言語Javaはこの本よりも厚いですしね。

プログラミング言語 Java 第4版

プログラミング言語 Java 第4版

膨大な範囲を扱っていますが、焦点を現場で使うものの現場の使い方に絞っているので、深さも十分なものになっています。 タイトルの「本格」にぴったり合っているんじゃないでしょうか。

微妙なところ

スベってなかった。

「ファイル操作を極める」のところが少々冗長と感じました。 ファイル操作のバージョンアップにおける変遷は業務では特に重要なので、Java6以前との対比は必要なんでしょうが・・・毎回繰り返す必要はないんじゃないかなーと。なんか他と記述レベルが違う感じ。

また、序盤に集中している*1のですが、誤りと思われる部分もそこそこありました。 ですが、ほとんどは現場では実害を与えるものではないと思います。 仮に現場で誰かが言っててもスルーする*2程度ですね。

気づいたところをつらつら書こうかなと思ったのですが、そもそも対象読者が気にするものではないと思ったので、今回は書かないことにします。 チラシの裏(gist)に書いてってるので、そのうちリンクしようかな・・・

こんな人にオススメ

メインは業務でなんとかコーディングしている3-5年生くらいのプログラマさんかな。 がんばって読み砕けば、きっと以前の自分のコードを見て「うわぁ・・・」とか思えるはず。 自分のコードにコレジャナイ感を持っているなら是非どうぞ。

また、10年以上経験のある方もアップデートに良いと思います。 最新をある程度キャッチできてるつもりの私も「あ、こんなのあったんだ」みたいなのはありました。 読んで損するものではないでしょう。

後半にかけて急激にレベルが上がるので、序盤をなんとか読める程度の方にはなかなかハードな気はします。 入門とはいえ決して軽い門ではありませんが、まあ「門にも色々あっていいよね」とか言ってる人もいるんでいいんじゃないかな。

*1:事実を説明している部分なので、理解の水準や説明のわかりやすさなどで難しい部分です。

*2:さすがに面と向かって言われたら訂正しますが。

DIコンテナのインジェクション方法の使い分けについて

DIコンテナを使う時にどのインジェクションを使うかって話です。 たぶん誰かがどこかで同じようなことを書いているだろうけれど、気にせず書くよ。 「他の誰かが書いている」なんてのを書かない理由にしてると何も書けなくなるし。

コンテナ
DIコンテナのこと。
コンテナ管理
インスタンスのライフサイクルをコンテナが管理していること。雑に言えば、使う側で new しないってこと。
インジェクション
Dependency Injectionのこと。

Short Answer

コンストラクタインジェクションを使いましょう。使い分けなくていいです。

3種類のインジェクション

インジェクションには3種類ありますね。他あっても知らない。

  • フィールドインジェクション
  • セッターインジェクション
  • コンストラクタインジェクション

フィールドインジェクション

一番よく見るかな。

class Hoge {

    @Inject
    Piyo piyo;
}

この状態でHogeをコンテナにインスタンス生成してもらうと、piyoフィールドにコンテナ管理されているPiyoインスタンスがインジェクションされる。 記述量が少なくて済むのは嬉しいですね。

このインスタンスをコンテナ外で生成して使おうとすると、piyoフィールドに何かしらの方法でインスタンスを設定してあげなきゃいけない。 何かしらの方法ってのは十中八九リフレクションですね。フィールドをpublicにする手もあるけれど、あまりしないかな。 コンテナでライフサイクルを管理したいオブジェクトは、プロダクトコードではコンテナ外で使いません(やっちゃいけない)が、テストコードではありえます。

問題点は、(リフレクションを使わない場合)テストでコンテナを使わないといけなくなります。 コンテナを使うと重くなります。 コンテナの重さはキャッシュやコンテナの高速化などで対応できなくはないです。 とはいえ、テストの重さがコンテナの起動時間に支配されている開発現場において、適切な対応がされることは稀です。 対応せずに放置すると、単純に時間がかかるのでテストの実行機会が減ります。とても残念ですね。

もう一つ問題があって、このオブジェクトがコンテナに依存することです。 せっかくDIコンテナを使うことで依存関係を逆転させたのに、DIコンテナを使わないと適切にインスタンス生成できない物体になっています。 なんというか、本末転倒感があります。 個人的にはこちらの理由で使いたくない。

セッターインジェクション

黎明期によく見たけど、最近はあまり見ないような。

class Hoge {

    Piyo piyo;

    @Inject
    void setPiyo(Piyo piyo) {
        this.piyo = piyo;
    }
}

この状態でHogeをコンテナにインスタンス生成してもらうと、setPiyo(Piyo)メソッドがコンテナ管理されているPiyoインスタンスを引数として呼び出される。 前述のリフレクション云々よりは挙動がわかりやすいですね。

コンテナ外で使う時も、自分でインスタンス生成してからセッターを呼び出せばいいだけです。

問題点は、セッターなこと。 って言うと趣味が入ってるように捉えられるかもですが、セッターを持つってことは、状態遷移があるってことなんです。 状態遷移があるオブジェクトは不安定です。組み合わせるともっと不安定になります。 疑心暗鬼になりながら使いたくないです。

なんだかんだで、コンテナ管理するインスタンスってコンテナ内ではシングルトンなことが多いです。 スコープを省略した場合のデフォルトがシングルトンなことからもわかるかと思います。 これはこれでどうなって思うのですが、まあ現状はそうです。 そんなインスタンスの状態が不安定とか言われると、私は落ち着いて開発できない。

私の心理的な安全のためにセッターインジェクションは使わないでほしいです。 フィールドインジェクションは「リフレクションを使う時点で危険なのをわかってやってる」と自分に言い聞かせることができるので、この点は許容できます。

コンストラクタインジェクション

なぜかあまり見ない。

class Hoge {

  final Piyo piyo;

  @Inject
  public Hoge(Piyo piyo) {
    this.piyo = piyo;
  }
}

この状態でHogeをコンテナにインスタンス生成してもらうと、コンテナ管理されているPiyoインスタンスがコンストラクタの引数として呼び出される。 インジェクションタイミングがわかりやすいのがいいですね。

フィールドインジェクションと比較して「インジェクションする数が増えると積み重なってすごく冗長になる」と言うのを聞きます。 でも、それだけ多くのものに依存している状態がそもそもおかしいと断言できます。

インスタンス生成時点で状態が安定するのが実に良い。 フィールドにfinalつけれるのが嬉しいです。 フィールドもローカル変数もデフォルトfinalにならないかなぁと常々思うけど、これは別の話。

<脱線> フィールドインジェクションはデフォルトコンストラクタなどでインスタンスを生成してから、フィールドにリフレクションで設定します。セッターインジェクションも同じです。 そのため、インスタンス生成直後に値が入ってなかったりします。 その間隙をついてNullPointerExceptionが起こったりすることも無いとは言えません。 実際起こることはあまりないのですが、疑いたくなる気持ちをわかってください。 </脱線>

また、インスタンス生成で必要なものがコンストラクタで明示されています。 テストなどのコンテナの外でインスタンス生成する際も特に制約はありません。

と言うことで、問題点は特に挙げられません。

なお、Springでもコンストラクタインジェクションは@Autowiredとか書かなくてもインジェクションしてくれるようになってたりします。 この辺もコンストラクタインジェクションの追い風。

なぜ複数のインジェクション方法があるのか

コンテナを作る側の都合かなーと。知らんけど。 使う側の事情でこの3種類のインジェクションを使い分けたことは今までなくて、多分今後もない。

インスタンスを生成するためにはコンストラクタを呼ぶ必要があります。 「コンテナ管理するにはデフォルトコンストラクタが必要」なんてのを見聞きしたことはあるでしょう。 これはインスタンス生成時にClass#newInstance()を使ってるから…なんて理由ではないと思いますが、ともかく単にインスタンス生成するだけならデフォルトコンストラクタが楽です。 コンテナに限らず、インスタンスを生成するライブラリがデフォルトコンストラクタを要求するのは珍しい話ではありません。 そう言えばClass#newInstance()がJDK9でDeprecatedになりますね。関係ないですけど。

話を戻して。コンテナを作る側の都合ではフィールドインジェクションが楽です。 コンテナ管理対象のインスタンスを一通り生成してから必要なインスタンスをインジェクションしていけばいいだけだからです。

コンストラクタインジェクションでは、コンストラクタが要求するインスタンスを先に生成する必要があります。 インジェクション対象のインスタンスがなければコンストラクタを呼び出せないですから。 こうなってくると、インスタンスの生成順を考慮しないといけなくなるわけで、コンテナが多段構成になっていたり、定義の上書きがあったりするととても面倒です。 依存関係の循環なども問題になってきます。

セッターインジェクションでも生成順は問題になってきます。 なぜならインジェクションで呼び出すのはメソッドなので、メソッドで引数のオブジェクトのメソッドが呼び出されるかもしれません。 「セッターではメソッド呼び出しをしないでください」とか言うわけにもいかないので、インジェクションするオブジェクトは完成している必要があります。

そんなこんなで、フィールドインジェクションが作る側の都合は楽っぽい。 その次にインスタンス生成がデフォルトコンストラクタでいいセッターインジェクションが楽で、一番面倒なのがコンストラクタインジェクションだったり。

まぁ、使う側にとっては知ったこっちゃないです。 使う側は安定した完成したインスタンスが手に入ればいいんで。

で、結論

コンストラクタインジェクションを使いましょう。

ことしのふりかえり

2016年12月31日です。 最近の日付表記のマイブームだと 2016-12-31T22:11 です。 大晦日ですね。

さて、今年を振り返ってみよう。 来年になったら忘れる、と言うかもう忘年会してるから忘れちゃってるんですが、なんとか引っ張り出して。

今年もなんだかんだで色々ありました。

対外的なこと

対外的な活動だとこんな感じですかね。

  • WEB+DB PRESSで「Javaの新定石」の連載
  • 2月関ジャバで「よくある業務開発の自動化事情」の再演
  • JJUG CCC 2016 Spring で「テスト自動化のまわりみち」の登壇
  • JJUG CCC 2016 Fall で「どうしようJUnit 5」の登壇
  • 大阪Jenkins勉強会 でのLT
  • 合同勉強会 in 大都会岡山 -2016 Winter- でのLT

お仕事のこと

お仕事では相変わらずJavaなプロジェクトでよくわからない立ち位置でいました。 プログラマなんですけどね。リーダー補助とか、なんだかんだと。

あと、今年の最初には全く予想もしてなかったのですが、なんだかんだで仕事がなくなりました。 なんの準備もしてないので1月から無職。自分でもびっくり。

今年の目標

今年の始まった頃は「xxxxやるぞー」とか思ってたりもしたのですが、 できたものもあれば、できなかったものもあり。

そういえば今月書いてたこの目標。

今年の目標を「1ヶ月に1エントリ以上のペースでブログを書く」にします。

Qiitaに1つ書いたので、それで12ってことで!

来年の抱負

らいねんかんがえる。

ご挨拶

みなさま、今年も一年お世話になりました。 来年もなんとかよろしくお願いいたします。

多くの人は忘れてるCoinの一つ

Java SE 7がリリースされたのは2011年7月。 さらに、パブリックアップデートが2015年4月で終了している子です。 5年も経てば一定の評価はできるでしょう。

さて、以下のコードをコンパイルしたらどうなるか。

void method() {
    try {
        throw new Exception();
    } catch(Exception e) {
        throw e;
    }
}

では次のコードは。

void method() {
    try {
        throw new RuntimeException();
    } catch(Exception e) {
        throw e;
    }
}

うん。

前者はコンパイルエラーで、後者は普通にコンパイルできます。

Project Coinの "Multi-catch and more precise rethrow" ですね。マルチキャッチの影に隠れてるから余計に目立たない。 Project Coinって言ったり、こうして書いてあることから思い当たったりする程度かと思います。 知らなかったり忘れてても問題ないものでしょう。

この機能、一度も使わなかったなぁ……。多分今後も使わない。

発端

このツイートで思い出した。で、こんなリプしたので

その「例外」の話、です。