Category Archives: オブジェクト指向・システム開発

自分の技術の棚卸し

新しい技術を学ぶときに大事なことのひとつに、自分の現在の技術の棚卸しをするということがあります。その時点での自分が持っている技術をできるだけ客観的に並べ、その並べたものと今から学ぼうとしてる技術とを比べて自分自身に何が足りないかを判断して、学ばなければならないことを見つけていくことが重要だと思います。また、この棚卸しと比較をしていくことで、新しい技術が登場したとしても、頭からすべてを学び直すことが必要なくなります。足りない部分だけ学んでいけばよいのです。あるいはすでに持っている技術に足して肉付けすれば済みます。
これはオブジェクト指向を学習していく過程でも同じで、自分が学んできたそれまでの技術、例えば構造化設計手法とオブジェクト指向との違いを確認していくことで、ある程度差分的に知識を増やしていくことができると思います。
ソフトウェア開発の現場では当然パラダイムシフトとよべれるような大きな変化がありますが、そのようなときでもこのやり方で乗り越えて良く事ができると僕は思っています。

オブジェクト指向でなぜつくるのか

たまに書籍の紹介を。また、申し訳ありませんがmixiのレビューに書いた内容とほぼ同じです。
オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識―
オブジェクト指向開発に関する入門書。オブジェクト指向の基礎概念、歴史的背景から、最新の開発方法論まで一通り網羅しています。
特にこの本が入門書としてすばらしいのは、オブジェクト指向プログラミングと、オブジェクト指向分析・設計をきちんと分けて説明している点、比較的平易な語彙を選んで書かれている点、余計な誇張や嘘が無い点が上げられます。
これからオブジェクト指向言語を学ぶ方、オブジェクト指向開発に新規にかかわる方は、詳細な個別技術ごとの書籍を読む前にウォームアップとして本書を読まれると良いでしょう。
また、プログラミング初学者の方は、本書を読む前にこのシリーズの第1弾を読んでおくことをお勧めします。

Continue reading オブジェクト指向でなぜつくるのか

スパゲッティってどうすればいいの その2

結局スパゲッティか、そうでないかの判断は、そのソースコードを書いている時の自分ではなくて、他人や3ヶ月後の自分が判断します。
つまり、如何に他者に理解してもらいやすく記述するかが大事です。難解な資本論を書く必要はないのです。
プログラムコードも自己の思考の表現方法の一つであるので、他人に理解してもらえるように記述しましょう。
せっかく苦労して書いたものが、ゴミのように捨てられたら悲しいでしょ。

スパゲッティってどうすればいいの

中さんのBlogに「スパゲッティに立ち向かうときのハウトゥ10カ条」がのっております。
すでにスパゲッティになってしまっているものに対しては、中さんのBlogのようにするしかないです。
逆にスパゲッティにさせない(しない)為にはどうするのがいいのかと言うことなんですけど、これはプログラムを適切なモジュールに分割して、その間のシーケンスとして設計し、コーディングしなさいと言うことになります。つまり、プログラムを一度で考えられる(管理できる)大きさに分割して、プログラムを分割統治せよと言うことになります。これをオブジェクト指向では、モジュールをオブジェクトと、シーケンスをメッセージパッシングという用語に置き換えます。
プログラムが人から見てスパゲッティと呼ばれるような状態になってしまうのは、充分に考慮せずにプログラムを作り始めてしまうため、本来プログラミングコードを書き始める前に終えておくべき思考が、コーディング中に行われ、思考の過程がプログラムコード中に分散して記述されてしまい、その結果収拾がつかなくなってしまうためです。つまり、設計が行われていないか、充分ではないために、プログラマの思いつきで関数の分割したり、不必要な構造体を作ったり、辻間あわせのグローバル変数を作ってしまう事になります。これでは、そのプログラマのコーディング中の思考の過程が他人や3ヶ月後の自分には理解が出来ないので、それらがそのプログラムコードを読もうとしてもわけのわからないコードとなってしまいます。
ですので、プログラムコードをスパゲッティにしないためには、コーディングを行う前に一呼吸置いて、自分が作るべきものが何者かを考えもう一度整理する必要があります。何も関数内のロジックを詳細にフローチャート化する必要もないとは思います(全部いらないって事じゃないですよ)が、モジュール化する単位と、各モジュールの関数間の関係とそれらの呼び出し順序ぐらいは紙にメモをとるなりしないと、コーディング中に収拾がつかなくなります。そしてそのメモは何らかの形で残すべきです。(本来はそれが設計書となっているはず。)
とりあえずは設計の重要性を認識する(してもらう)事が、スパゲッティコードを書かない、または、それを修正しなくてすむようにするためには必要となります。

J2SE Ver. 1.5

Java Ver1.5というか、Java2 Standard Edition Ver5について変更点がまとまっているところがないかなーとさがしていたのですが、以下のページがばっちりでした。
J2SE5.0トラの穴
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/contents.html
しかし一番の謎はJavaのバージョニングですね。なぜVer.5.0。

パターンランゲージ

koidoさんのblogにトラックバック
ソフトウェアシステム工学におけるパターンランゲージを考えるのであれば、あまり入り込まずにもう少し緩やかにパターンランゲージをとらえてみてはどうでしょう。
パターンランゲージ自体は明文化されたいない経験則を論理的に他者へ伝えるための方法論だと思います。
たとえばある都市構造や家屋の構造の中に存在する経験からなる普遍なものを抽出して、理解し、つまりは抽象化して、それを記述する手段とがパターンランゲージであり、その結果がアレクサンダー氏の著書だと思います。
ですので、ソフトウェア設計作業の中にある普遍的なものを抽出して、解釈、記述したものがソフトウェアデザインパターンになりますし、分析作業に対して同様のことを行うとアナリシスパターンになり、古今東西のソフトウェアアーキテクチャをぎゅぅっと絞って出てきたものが、アーキテクチャパターンであるといえるのではないでしょうか。