# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
本書の内容は，オープンソースモデルに従い，
ほぼ無制限で利用が可能です．
クリエイティブ・コモンズ表示3.0の条件下で，
自由に使用することができるのです．
つまり，どのエッセイも，
著者の名前を明記すれば，自由に転載，改変が可能であるということです．
ーー"はじめに"から抜粋 pXII
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
また，元の英文によるエッセイを読みたい方は，
こちらを参照して下さい．
Contributions Appearing in the Book - Programmer 97-things
31. 状態だけでなく「ふるまい」もカプセル化する アイナー・ランドル (Einar Landre)：『プログラマが知るべき97のこと』
システム理論(Systems Theory)において，
大規模で複雑な構造のシステムを扱う際に，
特に重要とされるのが
「封じ込め(Containment)」
です．
ソフトウェア開発に携わる人なら，
封じ込めもしくは，
「カプセル化」が
いかに重要であるかは十分に理解しているでしょう．
プログラミング言語も，
やはり封じ込めを考慮した作りになっています．
サブルーチンや関数，モジュール，
パッケージ，クラスなどの
要素を組み合わせて，
コードが書けるようになっているのは，
そのためです．
モジュールやパッケージは大規模なカプセル化に対応し，
一方，クラスやサブルーチン，関数などは，
もっときめ細かいカプセル化に対応します．
長年の経験でわかったのですが，
そうした要素の中でも，
開発者にとって正しく使うのが最も難しいのは，
「クラス」のようです．
mainメソッドだけで3000行もあるようなクラスや，
プリミティブ型のsetメソッドとgetメソッドだけで，
成るようなクラスも決して珍しくありません．
そういうコードを見れば，
関わっている人間がオブジェクト指向を
十分に理解していないことが，
すぐにわかります．
オブジェクトの「モデル」としての側面が
まったく活かされていないからです．
POJO(Plain Old Java Object),
POCO(Plain Old C# or Plain Old CLR Object)
という言葉に日頃から慣れ親しんでいる開発者にとって，
この言葉は「オブジェクト指向は，モデリングパラダイムである」
という主張が込められた言葉であり，
その原点に返るべきという主張が込められた言葉です．
オブジェクトはあくまでもシンプルなものであるべきですが，
「シンプル」と「なにも考えていない」は大きく違います．
オブジェクトは，状態と「ふるまい」の両方をカプセル化できます．
また，ふるまいがどういうものになるかは，
その時々の状態によって変わります．
「ドアオブジェクト」を例に考えてみましょう．
ドアには，
「閉じている」，「開いている」，「閉まる途中」，「開く途中」
という４つの状態があります．
また，ドアの操作には，「開く」と「閉じる」という２種類ががあります．
ただ，同じ「開く」や「閉じる」であっても，
その時々のドアの状態によって振る舞いは違ってきます．
このように，個々のオブジェクトが
元来どういう特性を持っているのかをよく検討すれば，
設計の作業は理論的にはさほど難しいものではなくなるはずです．
突き詰めると，すべきことは２つしかありません．
１つはオブジェクトへの責務の割り当て，
もう一つは他のオブジェクトへの責務の委譲です．
それにはオブジェクト間の相互作用についてのプロトコルが関わってきます．
理解しやすいよう，一例をあげておきましょう．
Customer,Order，Itemという３種類のオブジェクトがあるとします．
Customerオブジェクトは，
信頼限度とクレジットバリデーションルールを保持するのが自然でしょう．
Orderオブジェクトは関連するCustomerオブジェクトを知っていて，
OrderオブジェクトのaddItemメソッドは，
customer,validateCredit(item.price())を呼び出して
信頼調査を委譲します．
メソッドが実行されて，信用調査が失敗に終わった場合は，
例外が投げられ，
購入は中断されます．
オブジェクト指向開発の経験が浅い開発者は，
上のようなビジネスルールを
すべて一つのオブジェクトに詰め込んでしまいます．
そして，そのオブジェクトに
OrderManager,OrderServiceといった名前をつけるのです．
そういう設計をした場合，Order，Customer,Itemといったクラスは，
「レコード型」とほとんど変わらないことになってしまいます．*1
３つのクラスからはロジックが完全に排除され，
数多くのif-then-elseから成る
一つの大きな手続き型メソッドに密結合してしまうでしょう．
そんなメソッドではバグが発生しやすい上，保守も難しくなります．
なぜかというと，
「ふるまいのカプセル化」がまったくできていないからです．
状態だけをカプセル化しても，
振る舞いのカプセル化ができていなければ意味がありません．
プログラミング言語には，そのための機能が用意されているので，
是非，積極的に利用すべきです．
■著者データ
[アイナー・ランドル (Einar Landre)]
25年の経験を持つソフトウェアのプロ．
開発者，アーキテクト，マネージャ，
コンサルタントとして仕事をしてきた他，
執筆やプレゼンテーションなども行ってきた．
現在はStatoiHydroの
ビジネスアプリケーションサービス部門に勤務し，
クリティカルな業務アプリケーションの開発，
アーキテクチャレビュー，
ソフトウェアプロセス改善などの仕事をしている．
StatoiHydro入社以前には，
開発者，コンサルタント，マネージャとして，
国際宇宙ステーション向けの通信プロトコル，OS，
テストソフトウェアのデザイン，
実装などに携わった．
最近ではプロフェッショナルコミュニティにも積極的に参加し，
論文を執筆，共同執筆するなどしており，
OOPSLAやSPE（Society of Petroleum Engineers:石油技術協会)で
プレゼンテーションを行ったりもしている．
特に強い関心を持っているのは，
オブジェクト指向プログラミングや自律システムの設計，
システムエンジニアリングプラクティスの活用，
アジャイル手法，ハイテク企業におけるリーダーシップなど．
ストラスクライド大学で情報技術の理学修士号を取得
また，CSDP（IEEE-certified software development professonal:
IEEE認定ソフトウェア開発プロフェッショナル資格）も持つ．
家族とともにノルウェー，スタンバンゲルに住む．
関連記事
1．分別のある行動 Seb Rose：『プログラマが知るべき97のこと』 - MY ENIGMA
2．関数プログラミングを学ぶことの重要性 Edward Garson：『プログラマが知るべき97のこと』 - MY ENIGMA
3．ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne：『プログラマが知るべき97のこと』 - MY ENIGMA
4．コーディング規約を自動化する Filip van Laenen：『プログラマが知るべき97のこと』 - MY ENIGMA
5．美はシンプルさに宿る Jorn Olmheim：『プログラマが知るべき97のこと』 - MY ENIGMA
6．リファクタリングの際に注意すべきこと Rajith Attapattu：『プログラマが知るべき97のこと』 - MY ENIGMA
7．共有は慎重に Udi Dahan：『プログラマが知るべき97のこと』 - MY ENIGMA
8. ボーイスカウト・ルール Robert C. Martin：『プログラマが知るべき97のこと』 - MY ENIGMA
9. 他人よりまず自分を疑う Allan Kelly：『プログラマが知るべき97のこと』 - MY ENIGMA
10. ツールの選択は慎重に Giovanni Asproni：『プログラマが知るべき97のこと』 - MY ENIGMA
11. ドメインの言葉を使ったコード Dan North：『プログラマが知るべき97のこと』 - MY ENIGMA
12. コードは設計である Ryan Brush：『プログラマが知るべき97のこと』 - MY ENIGMA
13. コードレイアウトの重要性 Steve Freeman：『プログラマが知るべき97のこと』 - MY ENIGMA
14. コードレビュー Mattias Karlsson：『プログラマが知るべき97のこと』 - MY ENIGMA
13. コードレイアウトの重要性 Steve Freeman：『プログラマが知るべき97のこと』 - MY ENIGMA
14. コードレビュー Mattias Karlsson：『プログラマが知るべき97のこと』 - MY ENIGMA
15. コードの論理的検証 Yechiel Kimchi：『プログラマが知るべき97のこと』 - MY ENIGMA
16. コメントについてのコメント Cal Evans：『プログラマが知るべき97のこと』 - MY ENIGMA
17. コードに書けないことのみをコメントにする Kevlin Henney：『プログラマが知るべき97のこと』 - MY ENIGMA
18. 学び続ける姿勢 Clint Shank：『プログラマが知るべき97のこと』 - MY ENIGMA
19. 誰にとっての利便性か Gregor Hohpe：『プログラマが知るべき97のこと』 - MY ENIGMA
20. すばやくデプロイ，こまめにデプロイ Steve Berczuk：『プログラマが知るべき97のこと』 - MY ENIGMA
21. 技術的例外とビジネス例外を明確に区別する Dan Bergh Johnsson：『プログラマが知るべき97のこと』 - MY ENIGMA
22. 一万時間の訓練 Jon Jagger：『プログラマが知るべき97のこと』 - MY ENIGMA
23. ドメイン特化言語 Michael Hunger：『プログラマが知るべき97のこと』 - MY ENIGMA
24. 変更を恐れない Mike Lewis：『プログラマが知るべき97のこと』 - MY ENIGMA
25. 見られて恥ずかしいデータは使わないこと Rod Begbie：『プログラマが知るべき97のこと』 - MY ENIGMA
26. 言語だけでなく文化も学ぶ Anders Noras：『プログラマが知るべき97のこと』 - MY ENIGMA
27. 死ぬはずのプログラムを無理に生かしておいてはいけない Verity Stob：『プログラマが知るべき97のこと』 - MY ENIGMA
28. 「魔法」に頼りすぎてはいけない Alan Griffiths：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
