ありがちなC言語プログラムの間違いここでは、C言語によるプログラミングでありがちな間違いを紹介します。 C言語によるプログラミングで犯しやすい間違いは、 C言語 FAQ 日本語訳 や Ｃ言語のよくある間違い に数多くの例が紹介されていますので、一度、目を通してみることをお勧めします。 ここでは、これらのページに見当たらなかった間違いの例を紹介します。 なお、C言語だけでなく、基本的にC++言語でも同じことが言えます。
良いシーケンス図を描くための発想法
UMLの図法の中でも、シーケンス図はとても良く使われるものの１つです。クラス構成が複雑なアプリケーションでも、メソッドの呼び出しを順に辿っていき、それをシーケンス図に描いてみると、処理の流れが理解できたりします。 しかし、シーケンス図は、単に処理や手続きの順序を示すためのものではありません。メソッドが多かったり、呼び出す順序が決まっているからと言って、単に、呼び出されるメソッドを順に並べただけのシーケンス図を描いてしまうことがありますが、それはあまり意味がありません。 ここでは、良いシーケンス図を描くための考え方を紹介します。 処理の流れを図で示そう ここでは例として、画面Ａで入力した値を、画面Ｂで表示するだけの、単純なアプリケーションを考えてみましょう。 このアプリケーションはとても単純ですが、きちんと設計書を書いておくことにしましょう。 ソフトウェアの仕組みは、図で示すと分かりやすくな
技術者の評価を下げる「悪い」コメントに注意しよう
ソフトウェアの受託開発や、オープンソースのプロジェクトでは、ソースコードが他の技術者の目に触れる。そのため、ソースコードから開発者の技術力が評価されやすい。 ソフトウェアの開発者は、モジュール分割やクラス設計には全力を傾ける。最近では、設計の完成度を高めるために、実装の後でリファクタリングを行うことも珍しくない。 だが、設計の善し悪しにこだわる開発者でも、ソースコードに書くコメントの品質までは、配慮が及ばないことが多い。コメントは本質的なものではないので、つい気を緩めてしまうのである。 ところが、開発者の希望に反して、ソースコードの読み手が印象を受けやすいのは、コメントの品質である。ソースコードから設計を読み解くのは容易ではないが、日本語や英語で書かれているコメントは目に付きやすい。 優秀な技術者の書いたソースコードでも、驚くほど「悪い」コメントが書かれていることがある。そのようなソースコ
実装が終わってからプログラム説明書を書こう
設計書と説明書は同じもの!? 一般的な開発手法では、はじめにソフトウェアの設計を行い、設計書を作成する。ここで提案する手法では、更に、実装の後にプログラム説明書を作成する。 これらはいずれも、ソフトウェアがどのような作りになっているかを解説するドキュメントである。よって、この２つのドキュメントの内容は、まったく同じになる。 では何故、はじめに設計書を作っているのに、改めて同じ内容の説明書を作らなければならないのだろうか。 設計書と説明書では、読み手が異なる 実装の前に作成する設計書とは違って、プログラム説明書は実装の後で、完成したソフトウェアを元に作成する。同じプログラムの作りを解説するドキュメントであっても、実装の前に書くのと後に書くのとでは、出来上がる文章は、まったく別物になる。 設計書は、これからどのように実装するか、その指針を書いたものである。つまり、実装を行う自分自身のために作る
究極のインターフェース指向設計
オブジェクト指向言語では、メソッドを定義しただけで中身を実装しない、インターフェースが登場します。 インターフェースを使うと、クラスやメソッドの再利用性が高まります。インターフェースさえ同じなら、同じコードを、いろいろなクラスに適用できるためです。 しかし、インターフェースを使うのは、コードを再利用するためだけではありません。たとえ再利用しなくても、敢えてインターフェースを作ることもあります。むしろ、再利用するか否かに関わらず、インターフェースを使うべきだ、という考えもあります。 ここでは本屋さんのシステムを例に、インターフェースの存在意義について考えてみます。 本屋さんのクラス設計 本屋さんですから、まずは「本」クラスが必要です。「本」クラスは、下記のようないろいろな属性を持ちます。 題名 著者 発行者 値段 重さ ページ数 次に、本を購入するための「会計システム」を作りましょう。 レジ
enum-j.html#java_enum
C言語によるプログラミングでは、列挙型(enum型)はたいへん良く使われます。 オブジェクト指向言語でも、それは変わらないようです。C言語を拡張したC++言語ではもちろん、Java言語でも、J2SE 5.0になってから列挙型が導入されたほどです。 その一方で、オブジェクト指向言語で列挙型を使う弊害も、繰り返し指摘されてきました。列挙型とswitch文を使ったソースコードは、ポリモーフィズムを使って書き直すべき典型的な悪い例として、しばしば取り上げられて来ました。 しかし、列挙型を使ったプログラムのすべてが、ポリモーフィズムを使って書き直すべきだとは限りません。継承によるポリモーフィズムは、オブジェクト指向の特徴の１つですが、サブクラスを作るべきではないケースもあるのです。そのような場合に、列挙型を使ったコードを書くことは、悪いことではありません。 ここでは、オブジェクト指向言語における列挙
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
