Dictionaryクラス使用時の注意点

Dictionaryクラスを使用するときに、注意しなくてはならない部分があります。

それは以下のサンプルコードを読むと、判りますが、勝手にリストに追加されてしまうということです。

Dictionary<int, int> data = new Dictionary<int, int>();
for (int i = 0; i <10; i++) data[i] = i * 10; 上記のようなコードを書くと、data.Add(i, i * 10)とプログラマが明示的に追加しなくてもリストに追加されてしまうということです。

明示的に追加メソッドをコールしていないのに、リストに追加されてしまうのは一見便利なようですが、バグを生む原因になってしまいます。

間違ってキーを設定して、値をセットすると、リストが元々意図した数ではなくなってしまう可能性があるのです。

プログラマがかなり気をつけて、コーディングしないと、勝手に追加されてしまうので、不要なものができてしまいます。

便利なようで、結構厄介なので、使用時には注意が必要であると思います。

ひどい対応があるものだ

先日、ある店頭のギフトセンターで注文をして、自宅に商品が届くようにして、何日か経過したので、今日、妻が問い合わせをしたら、その配送のところでとまっているといわれて、調べるので、折り返し電話をしますといって、いったん電話を切りました。

中々電話が来なくて、約2時間近く経過して、電話をしたところ、今から電話をしようと思っていたと、ヘルプデスクに言われて、ちょっと気分を害した私が電話を変わり、話していると、突然そこのリーダーの人が電話を変わり、話をしました。

そもそも、まず、電話をするといって約2時間も待たせることがありえない。待たせるのなら、いったん「調べるのに時間がかかっているので、もうしばらくお待ちください」と中間報告をすることが大前提にあります。

次に、そのリーダーが言ったのが、店頭のギフトセンターの人の説明が悪いといっていましたが、私からすると、それは全く論点が違っていて、まずは誤ることからではないかと思います。私からすると誰が悪いは、内部的なことは全く関係ありません。こちらの要求を満たしてくれればいいわけです。

かなり有名なデパートのギフトセンターで老舗と呼ばれるところです。あまりにもひどい対応でした。もう二度とそこでは注文をしないようにしました。

非常に細かなことですが、そういったことができていないのは、社会人としてどうなのかなと思う1件でした。

Dictionayクラス

最近、モデルを作成してちょっと仕様的にガチガチになっているなと思い、動的に生成できるように変更しています。

言語は、C#なので、Dictionayクラスを使用して、Keyに生成するものを渡していけば簡単にできるなと思いました。

このDictionayクラスは非常に便利です。基本は、Hashtableと同じなので、O(1)の操作になります。アクセス速度も非常に速いし、使い勝手がいいと思います。

ただ、注意しなくてはならないのは、直接アクセスできるようにすると、カプセル化ができなくなってしまうので、その点だけは使用時に注意が必要です。

プログラマのエゴだよな

プログラマに割りと多いのが、何でも自分でシステム化しようとする傾向が強いのかなと思います。

私もプログラムがある程度作成できるようになった頃に、何でも自分で作成しようと思ったり、Excelでできることを、システム化してしまったりしました。

これって自分で言うのもなんですが、プログラマのエゴだなと思います。
正直、Excelを使用したほうが導入までが早いし、手がかからないことが割りと多くあります。

それ以外のツールにしてもフリーソフトで色々とあります。

何でもシステム化するのは、やっぱりプログラマに多いのかなと思います。

まずは、利用シーンを明確にして、ネットで検索してなさそうなら作成するのがいいと思います。

ただし、自身の勉強の為に作成するのは、目的が異なるので必要になります。

ちょっとした気付きを大切に

子供のお風呂をためるのに、大体何分くらいためれば、ちょうどいいかを時計を見ながら時間を計っています。

そこで、キッチンタイマーのようなものが携帯電話にあればいいなと思いました。
そこで、自分でキッチンタイマーのAndroidアプリを作成すれば、市場に貢献できるなと思いました。

そもそもスマートフォン市場に投入するのに、利用シーン（ユーザーストーリ）的なものからはじめないと、全くの無名なところがはじめるのは非常に難しいと思います。

こういったことができますよといった利用シーンを明示してこそ市場への影響は大きいと思います。

そんな話をしていたら、そもそも普通の携帯電話にタイマー機能があることを今日知りました。普段、メールと電話帳と電話くらいしか利用しないので、全く知りませんでした。

勝手に貢献できると思っていましたが、すでにあるので、作成しても全く価値を生み出さないので、作成するのはやめますが、ちょっとしたことでも気がついたことを人に話して精査していく必要があるし、そういったものを大切にしていきたいと思います。

ワークフローシステム

最近、様々な文書を整理していると、これは承認されているのか・されていないのかが非常に不明確なものが多々あるなと思いました。

それ以外にも思うことがあり、勉強を兼ねながらワークフローシステムを構築することを考えています。

基本的にはWEBアプリにしようと考えていて、サーバーサイド・クライアントなど考えることが非常に多くあります。

初めてに近い状態でWEBアプリを作成するので、どこから進めていく必要があるかを調査しています。

Javaの勉強を兼ねながら行いますが、ワークフローのエンジンがどうもあるようで、JBossやBuriというものが存在します。

とりあえずサンプルを作成してみて、色々と決めていこうかなと考えています。

Windows7のライブラリ

Windows7から導入されたライブラリというフォルダが存在します。

このライブラリとは、ユーザーがいろいろな場所に作ったフォルダを一つにまとめて表示できるようにしてくれる仮想フォルダのようです。

使用用途としては、HDD内に散乱したファイルを、テーマに合わせてフォルダごとまとめて管理しやすくなるということがネットにかかれていました。

私の勝手な感覚からすると、どこに保存するかをあらかじめ決めておけばこのような仕組みは必要ないのではないかと思います。

例えば、ソースコード用のフォルダを「Source」だったり、文書関連のフォルダを「ドキュメント」としておけば必要ないのではないかと感じます。

イマイチ、使用用途が不明なものができたなという印象が強い機能の一つです。

テクニックを学ぶ前に重要なこと

クラス設計をする上で、オブジェクト指向やデザインパターンなど様々なテクニックなどがあります。

それらテクニックを学ぶ前に、生成期間が異なるもの・データと表示に関するものを一つのクラスにしてはいけません。

生成期間が異なるものとは、あるデータは、システム終了まで保持されますが、あるデータは、システムでの一部の区間しか生成されないものなどです。

データと表示に関するものも結構一緒になっているようなコードを見ることがよくあります。

そこを改善しないと、デザインパターンや様々なテクニックを学んだところで全く意味がありません。

上記の内容のようなコードになっている場合にはたいていテストコードが無いので、結構厄介な修正になったりする場合があります。

レガシーコードとは？

最近、知った言葉でレガシーコードというものがあります。

これは「テストがないコード」のことを言うそうです。

数年前の私であれば、レガシーコードを書いていました。

最近はテストコードがないと不安だし、怖いので、必ず書くようにしています。

逆にテストコードがないソースを変更するのは非常に勇気？（半ば諦め）がいることです。

つい先日、テストコードがない製品のデバッグをしましたが、ビックリしました。
最近であれば、テストコードを書くことが必須になっているのに、書かれていないのです。

構造的にテストコードがかけない部分もありますが、見たら大体テストコードが書けそうだったので、まずはそこから書いてきました。

自分の作成したコードを綺麗にするとか、後々わかりやすくしようというものがかけているように感じるコードでした。

自分もこのような状態にならないようにしていかなければならないと感じました。

検討の為のコーディング

最近、他のプロジェクトのモデルのレビューをしたり、コードのレビューをする機会が増えています。

そこでクラス図を見やすいようにデジタル化してくれていますが、何度もやり直しをしたり、中にはこのクラスは必要ないものも存在しています。

それをいちいちデジタルで編集すると非常に面倒だったので、印刷してくれとお願いをして、これは不要で、このクラスに結合すればよいなどを紙に直接書いてレビューをしています。

また、表示の設定とデータが結合しているクラス（疎結合になっていない）ものも分離するのに、やはり手書きで書きました。

だんだんと不要なクラスや表示とデータを分離することができて、すっきりとしたクラス構成になったのでないかと思います。

ただ、これを自分で実際にテストコードを書いて、実装して、Viewに接続したときに上手くいかなくなる可能性がないわけではありません。

何度もこのブログ上で書いていますが、最終的にいけると感じたときにデジタルにしておけばすむので、それまでは手書きで書いたほうが非常に効率がいいと感じます。

ここ2日くらいでだいぶ形になってきたので、後は実際にコードを書いてみてコードをレビューしながらより良い形になっていくのではないかと思います。

ちなみに自分が担当しているプロジェクトでは人数もそんなに多くないので、私が書いた手書きのクラス図を壁に貼り付けて、検討する際には、赤字で修正をしています。まったくダメな場合には書き直して、アーキテクチャの検討を進めています。