2002/06/28 undo
きれいなおねぇちゃんと話しています。しかし、相手が何についてしゃべっているのか、さっぱり分かりません。なんとか理解しようとするかもしれません(^^;;
しかし、経験上、こういうときは、しゃべっているほうもたいてい何について、しゃべっているか考えてないです(^^; なんとなくしゃべっているだけなんですね。はっきりと話す内容がまとまっていないのです。みかけはキレイでも話もキレイとは限らないわけです :-p
プログラマは、こんなのでは困ります。『違いの分かる』プログラマになりましょう。手始めには、設計なり仕様なりの話をするとき、「役割」と「機能」と「インタフェース」と「実装」をきちんと区別しましょう。たとえば、設計変更するとき、「役割」を変更したいのか、「機能」を変更したいのか、「インタフェース」を変更したいのか、「実装」を変更したいのか、よ〜く考えてみてください。そうでないと、何の話をしているのか、どうしてそういうふうに決めたのか、どうして修正したいのかなどが明確になりません。明確にならなければ、相手に通じなくてもあたりまえです。最悪なのは、お互いに勝手に解釈して納得してしまうことです。
「メソッドはクラスの顔」です。役割や機能を表すような名前やインタフェース仕様にすべきです。たとえば、メソッド名は「GetString()」よりも「GetName()」のほうが機能がはっきりします。「SetName(String*)」よりも「SetName(const Name*)」のほうが引数に対する仕様がはっきりします。単にメソッド名や引数のデータ型を変更しているのではなく、機能をはっきりさせるためにインタフェースを変更しているのです。いいかえれば、インタフェースに現れていなかった(あいまいな)機能をインタフェースで明確にしているのです。この場合、機能に変更はないかもしれません。しかし、インタフェースを変える理由は機能にあるのです。「名が体を表す」インタフェースのほうがよいインタフェースと言えます。
今、あなたが書いているクラス図は何を説明するためのものですか？
用語も正しく使い分けましょう。overload, override, overwrite, overflow, overhead、全部区別できますか？