java:重複を排除する方法3選

今回は、javaでListの重複排除を行う方法を3つ紹介します。

1つ目の方法は、for文で自力でアルゴリズムを記述して重複排除を行う方法です。
記述が冗長になり、コーディングミスも起こりやすいことから、現在の実務ではこの方法で重複排除を行うことはないと思います。
しかし、新人研修でjavaの標準APIの学習が不十分な段階で使うケースが想定される他、実務でもCOBOLからjavaにコンバージョンしている等のレガシーな環境では見かけることがあるかもしれません。

2つ目の方法は、HashSet(順番を保証する必要がある場合はLinkedHashSet)を使用する方法です。
HashSetとは、重複を排除して要素を格納するクラスであり、自力で重複排除のアルゴリズムを記述する必要がないためコーディングミスは起こりにくいです。
コンストラクタでListとSetの相互変換も可能であることもあり、記述も簡潔になります。
実務ではHashSetを使うケースが多いと思います。

3つ目の方法は、StreamAPIを使用する方法です。
StreamAPIにはdistinctメソッドが用意されており、このメソッドを呼び出すことで重複排除が可能です。
Java8から導入された機能であり、背景に関数型プログラミングの考え方があることから、昔からjavaを書いてきた人は取っつきにくさを感じるかもしれません。
しかし、新しい物好きの現場ではStreamAPIの使用が好まれるでしょう。

以下、サンプルコードです。

【サンプルコード】

【実行結果】


いかがでしたでしょうか。

新人研修で重複排除の方法が話題になったので、この記事を書いてみました。

javaは歴史の長い言語であるため、一つのことを実現するだけでも色々と書き方があります。
また、今回紹介したように、時と場合により、どのような書き方をするか使い分けすることが望ましいです。

Word:改行時に勝手に番号が割り振られないようにする

Wordを使っていて思い通りに文書が書けないことは良くあります。
良くある悩みの一つは、「勝手に番号が振られてしまう」というものです。

例えば、「1.ほげ」と入力して、Enterを押下すると、以下のように勝手に番号が振られます。

「1.」と入力すると、段落が入力されたものだとWordの内部で判断されるため、このような挙動となります。

お勧めの解決法は、Shift+Enterで改行することです。
Shift+Enterで改行することで、「箇条書きは続いているけど次の箇条書きには移っていない」とWordの内部で判断され、内部的にも見た目的にも上手い具合になります。 次の箇条書きに移りたい時は、Enterで改行すれば良いです。

なお、よく見る解決法として、箇条書きの自動設定をオフにするという方法があります。
しかし、この方法には、既定の設定を変更するのは面倒という欠点があります。
また、自動で箇条書きになるというのを理解していれば箇条書きしたい時にEnter一つで箇条書きにできるので、箇条書きの設定は必ずしも不便な設定というわけではないです。

他の解決法としては、自動的に番号が振られた後にCtrl+zで自動操作を戻し箇条書きを解除するという方法が挙げられることもあります。
この解決法を用いると見た目を整えることはできますが、改行した箇所以降は箇条書きではないとWordの内部で判断されてしまいます。
箇条書きの機能自体は理解していれば便利(例えば目次を自動で作ることができる)なので、Wordの良さを活かすという意味で言うとこの解決法もあまり良くありません。
(見た目だけ整えれば良いのであれば、それこそExcel方眼紙の方が良いという話になってしまいます)


いかがでしたでしょうか。

SIerの業界では「Excel方眼紙は慣れているけどWordには慣れていない」という人が少なくないと感じたので、このような記事を書いてみました。

ちなみに、Word以外にも、Enterだと段落が変わりShift+Enterだと通常の改行が行われる、という挙動のソフトウェアが存在します(例えばコミュニケーションツールのConfluence)。
Shift+Enterは半ば一般常識化している面もあるので、通常の改行はShift+Enterで行うという癖を身に付けておいても良いかもしれません。

動的計画法を試してみた

動的計画法とは、再帰的なロジックを、計算結果を都度記録するロジックで代替することで、計算速度を向上させるテクニックです。
競技プログラミングのテクニックの一つなのですが、高度なアルゴリズムを実装する開発だけではなく普通の業務システム開発にも応用できそうなので、紹介します。

今回は、フィボナッチ数列の計算を例に挙げます。
再帰的に処理した場合、数列が1つ増える度に呼び出し量が2倍になるため、オーダはO^2となります。また、再帰的に関数を呼び出すとその分メモリ(スタック)を消費するため、異常終了するリスクも高くなります。
しかし、動的計画法を用いた場合は、数列が1つ増えても計算が1回増えるだけなので、オーダはOとなります。
実際に45項目を計算した結果、再帰呼び出しでは約11000ミリ秒を要しましたが、動的計画法の場合は1ミリ秒未満でした。

【スペック・動作環境】

・OS:Windows8.1 64bit
・CPU:Inter(R) Core(TM) i5-4210U CPU @ 1.70GHz 2.40GHz
・メモリ:8.00GB
・ディスク:SSD 128GB
・言語:java8
・IDE:Eclipse Oxygen

【確認用プログラム】

【実行結果】


いかがでしたでしょうか。

業務システム開発に携わっている身としては競技プログラミングは少し縁遠い存在なのですが、再帰呼び出しは業務システム開発でも使うことがあります。
(直近ではGUIの開発で使いましたし、現在趣味で作っているプログラムでも再帰呼び出しの箇所が存在します)
再帰呼び出しを使用するとどうしても重くなったり異常終了したりすることがあるので、そのような場合に動的計画法の使用を検討できると実装の幅が広がると思いました。

続・singletonとstaticの違い

こちらの記事について社内外でちょっとした議論になったので、その内容をまとめてみました。
Singletonパターンを利用する理由は「外部からnewさせたくないから」だと思っていましたが、「そう書いた方がわかりやすいから」「staticではないメソッドも利用可能になるから」という理由の方が大きそうです。

【指摘】

・privateコンストラクタを持った時点でnewできない

newさせたくないだけなら、オブジェクト取得メソッドは不要。
Singletonパターンで無くても良い。

・Singletonパターンの思想の表現としてオブジェクト取得メソッドが必要

書籍ではSingletonパターンはオブジェクト取得メソッドが必要とされている。
確かに、privateでオブジェクトを1つ生成、外部にはメソッド経由で提供する、とすれば、「オブジェクトは1つのみ存在する」という思想をわかりやすく表現できる。
人によってstaticの方が分かりやすいかSingletonパターンの方が分かりやすいかは違うと思うが、オブジェクト指向に慣れた技術者であればSingletonパターンの方が設計思想が分かりやすいというのはありそう。

・Singletonパターンだとstaticではないメソッドも参照可能になる

Singletonパターンであればクラスへの参照ではなくオブジェクトへの参照となる。
そのため、staticではないメソッドの参照も可能となる。
具体的には、継承・オーバーライドができるというメリットがある。

【サンプルコード】

・StaticMemory.java

・SingletonMemory.java

・SingletonMemoryChild.java

・MemoryTestMain.java

【実行結果】


この話、社内でちょっとした議論になりました。
おかげで色々理解が深まりました。

議論のきっかけを作れるというのも、技術ブログの良い所だと思いました。

java:実務で使うテクニックでfizzbuzzを解いてみた

10年ほど前に流行ったプログラミングの問題として、fizzbuzzと呼ばれる問題があります。
この問題は、応募者のプログラミング経験の有無を見極める問題であり、問題の内容は以下の通りです。
・1から100までの数を出力する。
・3の倍数の時は代わりに”fizz”と出力する。
・5の倍数の時は代わりに”buzz”と出力する。
・3の倍数かつ5の倍数の時は代わりに”fizzbuzz”と出力する。

「実務ではfizzbuzzのようなプログラムを書くことは無いから解けなくても良い」という意見もあるようですが、個人的にはfizzbuzzで使うテクニックは実務でも使えると思っています。

以下では、実務でも使うテクニックを用いてfizzbuzzを解いてみます。
(言語はjavaです。今回の記事の趣旨上、トリッキーな解答は除外します。)

・剰余を用いた一般的な解答パターン

恐らく、これが一番自然な解答なのではないかと思います。
剰余を用いて、「n % m == 0」と記述することで、「m毎に何かをする」という記述が可能になります。
性能の観点で、一定のデータが溜まってからまとめてログ出力やデータベース書き込みを行うことがあるのですが、そのような処理を記述する時に使えます。
その他、テストデータを生成する時にも、この書き方を用いると楽になる場合があります。
(例えば、100個データを用意し、その内偶数のデータについては特定のフラグが立ったデータにする等)

・同じ分岐の記述を避けるパターン

先に挙げた解答では「3の倍数の時」「5の倍数の時」の分岐が2回ずつ出現し、若干冗長なので、このように同じ分岐の記述を避ける解答もあります。
同じ分岐を複数記述すると、保守性が低下します。
(例えば、「3の倍数」を「4の倍数」としたい時に、修正漏れが発生する可能性が出てくる)
プログラマーは保守性にも気を配るべきなので、個人的にはこちらの解答の方がよりプログラマーっぽいと思っています。

・除算と乗算を組み合わせるパターン

剰余を使わずとも、整数型は小数点以下切り捨てになるということを知っていれば、このような解答を記述することもできます。
除算で小数点以下の切り捨てが発生する場合、同じ数で乗算を行っても元の数に戻らないので、それを利用しています。
除算による切り捨てを実務で用いる場合もあり、例えば100未満の位を切り捨てしたい場合は、「n = n / 100 * 100」と記述したりします。逆に切り上げたい場合は、「n = (n + 99) / 100 * 100」となります。
現代のプログラミング言語では切り捨てや切り上げを行う便利な関数が用意されているのでこのような書き方をすることは少ないですが、このような書き方を知らないと他の人のプログラムを読んでいて困ることがあるので、知っておいた方が無難です。

・カウンターを持たせるパターン

fizz用のカウンターとbuzz用のカウンターを持たせて、カウンターを上手く制御すると、剰余や切り捨てを利用しなくても解答を記述できます。
実務では、カウンターの数字自体に意味がある場合にこのような書き方をします。
例えば、「ログ1→ログ2→ログ3→ログ1…とローテーションさせたい」という場合に、「ログ1」「ログ2」「ログ3」の数字部分にカウンターの値をそのまま用いることができます。


いかがでしたでしょうか。

今回紹介した問題は難しくないものですが、その解き方で個性やテクニックを発揮することができそうなので、今回は色々と解答を紹介してみました。
実務で役に立つ問題があれば、これからも紹介していきたいと思います!