適当に気になった技術や言語、思ったこと考えた事など。Tipsここで言う状態とは、クラス変数と振る舞いの状態を意味します。なったらメソッドの挙動が変わるなどです。インターフェース実装クラスなんかがそれに当たります。実行したあとでメソッドを呼び出すと例外を吐き出すようになります。後は使用不可(例外)を吐き出すだけまだマシと言うものでしょう。怖いのは「動作が変わる」と言うパターンです。クラス自体が状態遷移図のようなものを持っている場合です。具体的にはこんな感じのクラス設計だ。経由でしか設定できない。メソッド呼び出しに順序が指定されている。メソッドの挙動が変わってしまう。状態が悪?こうしたクラス設計とは、つまりクラスの内部的な動作を知らないと、意図した結果が得られない事を意味する。状態の変化と言うのはあって当然だったと思われる。現実的にも自販機などのようにお金を投入された状態(ドリンク選択待機状態)など、状態を持つものは多い。オブジェクト指向の本質、抽象化による現実の模倣(車とかがよく例に出されるが、それも状態だらけだ)としても、状態を是としている。いくつかの理由で、これはバグを産みやすくなる。(先に挙げたように)クラスの内部実装を理解していないと、正しく使えない。「この動作はこの機能の実装にも必要なんだけど...」と思った時に、そのクラスのコードを全て理解しないと使えないという事だ。状態がなく、クラス/メソッド名が確かなら、そもそもインターフェースだけで使い方がなんとなくわかる筈なのにも関わらずだ。状態を持ったオブジェクトはテストしづらい。クラス内の状態を2変数で持ったとしましょう。1変数で操作される状態数」と倍数的に増えてしまう。テストせずにリリースする訳にも行かないでしょう?テストコードを書かないとしても、結合テストでは、ここの分岐を動かすための操作、事前条件を整えるのが難しくなる。したものは、結合レベルでは見逃す事も多い。安心して他のメソッドに渡せない。オブジェクトに状態があり、それが書き換え可能だと、メソッド引数に入れて渡した時、その先で書き換えられてしまう恐れがつきまとう。それを避けるために、全ての手続きを追いかける必要性をプログラマに課してしまい、その行き着く先は1メソッドに全て記述する巨大な手続きだ。多くのプログラマが全力で嫌がるCOBOLバッチの世界へようこそ...。常にコード内でオブジェクトの状態を確認しなければならない。メソッドによってオブジェクトの状態が変わるという事は、メソッドの呼び出し順序にすら制限しかねない不安定なものになる。次に待っているのは、その状態をフルコントロールするための状態確認処理の増加だ。それはビジネス的に本質的なものではなく、可読性を損う。状態を持てば持つほど、それを使用するプログラムはそのコントロールに手間を裂く必要に迫られ、複雑化を招いてしまう。これは保守性とは相容れない。