SRP, OCP, LSP

「アジャイルソフトウェア開発の奥義」の読書メモ。
「アレ、なんだっけな」となりそうなのでメモしておく。

単一責任の原則(SRP:Single Responsibility Principle)

クラスを変更する理由は1つ以上存在してはならない

1つの役割とか、1つの責務、とか言わずに、1つの変更理由としているところが運用のための工夫らしい。

オープン・クローズドの原則(OCP:The Open-Closed Principle)

ソフトウェアの構成要素(クラス、モジュール、関数など)は拡張に対して開いて(オープン:Open)いて、修正に対して閉じて(クローズド:Closed)いなければならない。

ポリモーフィズムを使いましょう、という話。

リスコフの置換原則(LSP:The Liskov Substitution Principle)

派生型はその基本型と置換可能でなければならない。

継承関係を用いるべき基準として、対象となるクラスがあらわす概念が「is-a」なことだけでは不十分。そのすべてのメソッドの振る舞いまで含めて同じ性質でなければ、クライアントを困らせるという意味。テンプレートメソッドパターン以外で継承を使うときは注意しないといけないなぁ、と思った。メソッドをオーバーライドをするときの注意事項も引用しておく。「ルーチンの再定義をする場合、事前条件についてはオリジナルと等しいか、それより弱い条件と置き換え、事後条件についてはオリジナルと等しいか、それより強い条件と置き換える

「成功者の告白」読んだ

神田昌典さんがはじめて書いたという小説形式の本。こんな風に始まる。

お金がほしい。広い家に住みたい。
そんな身勝手な欲求で、僕はサラリーマンから逃げ出すように独立した。
お金儲けに関する本を貪り読んだ。
はじめは半信半疑だった成功法則も、やってみたら本当に結果が出た。
走って、走って、走りつづけた。銀行残高は増え、広い家に住めるようになり、憧れていたスポーツカーも買った。
気づいたときには、お金儲けの天才と呼ばれるようになっていた。
ハッピーエンド。誰もが羨む成功物語だ。
しかし成功法則には、書かれていないことがあった。

成功への道のりには、いくつもの地雷が埋められていたのだ。

もちろん、内容も濃かったけど、とても驚いたのは、読ませる本だったこと。著者の学習能力なのか才能なのか、分からないけれど、これで小説形式が「はじめて」なんて凄すぎる。

iMindMapデータ

MindMap(画像)

ATOK X3 forをOpen SUSE 10.3 Desktop にインストールしたら、YaST2が動かなくなった。

http://forum.ubuntulinux.jp/viewtopic.php?id=1152&p=2:Ubuntuのフォーラム]を参考に以下のようにしたら動いた。

/sbin/yast2 の2行目に以下を記述して保存(要root権限)



GTK_IM_MODULE=xim

Linuxは色々うまく行かない事が多いけど、今回は解決できたので嬉しい。

働く気持ちに火をつける—ミッション、パッション、ハイテンション!読んだ

「働く気持ちに火をつける—ミッション、パッション、ハイテンション!」を読んだ。

情熱をもって取り組んでもらうために、ミッション(仕事)を与える側が注意すること。

  • 明確にしなければならないこと
    • 期限
    • 結果
    • いずれも「ぎりぎりポッシブル」であること
  • 明確にしてはいけないこと
    • 手段
      • 「任されている実感なくしては能力を発揮できない」

その他、気に入った言葉・気になった言葉

  • 井上陽水は、ある本でこんなことを言っていた。曲をつくるのはものすごくクリエイティブな作業のように思われているが、「襖職人」のような感覚に近いという。「基本的には襖張りと同じです」という言葉が印象的だった。
  • 仕事が嫌になってしまう理由として、忙しい、つらいという以上に、飽きる、退屈だ、つまらないということがよくある。単調さの中に、どうやって快感を見つけるかの回路をつくり損ねてしまったケースが多い。

Enumまたはタイプセーフenumイディオムを使う – 定数を定義するためだけにインタフェースを使わない

時々、こういうコードを見かけないだろうか。



public interface XxxConst{

public static final String XXX_TYPE1 = "TYPE1";

public static final String XXX_TYPE2 = "TYPE2";

public static final String XXX_TYPE3 = "TYPE3";



public static final String AAA_ENABLED = "1";

public static final String AAA_DISABLED = "0";



//...つづく

}

このような「定数を定義するためだけのインタフェース」*1が私は嫌いだ。

理由は以下のとおり。

  • 最初に書いた人は良いけど、そこに何かが追加されるにしたがって、どこに何を追加すべきなのかを判断するのが簡単ではなくなっていく。使う方だってわかりにくい。そのinterfaceのメンバ数が100を越えて「XXX_TYPE1とXXX_TYPE1_CDって何が違うんだ? 僕はどっちを使えば良いんだ?」と皆に訊いてまわるのは嫌だ。(そして誰も答えられなかったりするし!)
  • こういうコードは、たいがいは片付けが貧弱で、せいぜいStringとintを使い分けてるだけっていうレベルだ。そんなコードを、コンパイルが必要なJavaでわざわざ書くというのは、なんか勿体ない感じがする。
  • 各定数に振る舞いを定義できないから、定数ごとに異なる振る舞いが必要になった場合は、その数だけ長い長いif,elseを書く必要がある。コードベースのあちこちに段々と増えていくそれを、全部もれなくメンテナンスするなんてウンザリする…。

「interface XxxConst方式は定義するのが簡単」という意見があるけれど、それは最初のうちだけだ。小さな書き捨てのプログラム以外では、すぐに今書いたような混乱が生じる。

では、どういう風に書けば良いのだろう?

Java5では、Enumが使えるようになった。それJ2SE1.4以前のバージョンでは、タイプセーフenumと呼ばれるイディオムを使って記述できる*2。このイディオムを正しく書くのはちょっと面倒だけど、EclipseのJETなどを使えばそれほどでもない。見返りのほうが断然大きい。

*1:標準ライブラリのBigDecimalクラスには似たような方法で丸め方法に紐付けられた定数が定義されている。あれは、丸め処理を書く必要にせまられた世界中のプログラマをイライラさせているのではないだろうか?

*2:Effective Java 98ページを参照