フローチャートを書く意義と書き方

フローチャートは、処理の流れを図に起こして整理するために使う技法です。
フローチャートを起こすことで、他の人に処理の流れを伝えやすくなるので、設計書では良く用いられます。
また、自分自身も処理の流れを理解しやすくなるので、複雑なプログラムを組む前に作ることも多いです。

特にプログラミングに慣れていない内は処理の流れを考えるのにも一苦労だと思いますので、プログラミングする前にフローチャートを書く癖を身に付けることをお勧めします。

以下、フローチャートの書き方や例を提示していきます。

1.フローチャートの例

フローチャートは、記号を線で結ぶことで作成します。
記号の中には具体的な内容を記述します。

フローチャートには詳細なものと概要を把握するものに大別できます。
詳細なフローチャートは、プログラムの1行1行を記号に落としていくようなイメージであり、すぐにプログラムに落とし込むことが難しい初学者にお勧めできるフローチャートです。
一方、概要のフローチャートは、処理の流れを俯瞰するためのものであり、実際のプログラミングでは1つ1つの記号の中で複数の処理(順次処理、分岐処理、繰り返し処理等)を記述します。設計書に用いられることが多いのはこちらのフローチャートです。

2.フローチャートの記号の意味

フローチャートで使われる記号の意味は以下の通りです。
これ以外の記号が使われることもありますが、これ以外の記号は現場や人によって微妙に書き方が異なることも少なくないので、実際のフローチャートを読んで都度記号の意味を考えた方が良いでしょう。

3.繰り返しや定義済み処理を含むフローチャートの例

前述の例では使用していない記号があったので、以下で補足します。


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

慣れない内はプログラムのロジックを考えるのに一苦労します。
いきなりプログラムを書き始めるのが難しい場合は、フローチャートを書く所から始めると良いと思います。

ちなみに、私も、難しい処理を実装する場合は自分のためにフローチャートを書きます。
つい最近も、再帰処理を含む複雑なロジックを4ページ程のフローチャートで整理していました。
慣れていてもフローチャートを書く時は書くので、慣れない内は尚更書いた方が良いのではないか、と思っています。

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

【実行結果】


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

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