オブジェクト指向設計の原則1

オブジェクト指向設計の原則１＿単一責務の原則＆開放/閉鎖の原則
1
オブジェクト指向設計の原則１
2
3
学ぶにあたってのゴール.........................................................................................................2
4
単一責務の原則（SRP: Single Responsibility Principle）...................................................2
5
開放/閉鎖の原則(OCP: Open-Closed Principle) ....................................................................4
6
用語集(wikipedia) ...................................................................................................................6
7
参考文献 ..................................................................................................................................6
1
オブジェクト指向設計の原則１＿単一責務の原則＆開放/閉鎖の原則
8
9
学ぶにあたってのゴール
10
11
1.
オブジェクト指向をより知る
12
2.
良い設計ができるようになる
13
3.
優れたオブジェクト指向技術者になる
14
15
特にデザインパターン(Gof)の多くが、オブジェクト指向設計の原則を適用しているので、
16
オブジェクト指向設計の原則を学ぶことで、より深くデザインパターンを理解することが
17
できます。
18
最高のゴールはフレームワークを作れる人間！
19
20
単一責務の原則（SRP: Single Responsibility Principle）
21
22
簡単にいうとどんな原則？
23
24
クラスを変更する理由はただ１つでなければならない
25
26
A class should have only one reason to change
27
具体的にいうと
28
なんでもかんでも一つのクラスに機能を押し込めすぎるなということです。機能ごとにク
29
ラスを分けるべきです。クラスは、ただ１つのことを知っていればよいのです。さらに言
30
えば、クラスの変更する理由はただ１つであるべきです。
31
次のクラス図を見てください。この社員クラスは多くのことを知りすぎています。給料と
32
税金の計算方法、自身をディスクに読み書きする方法、自身を XML に変換したり XML か
33
ら戻す方法、自身を各種のレポートに印刷する方法などを知っています。SAX から DOM
34
に変更する場合、MySQL から Postgres に変更する場合、税金の書類の形式を変更する場
35
合も、Employee クラスを変更しなくてはいけません。
36
2
オブジェクト指向設計の原則１＿単一責務の原則＆開放/閉鎖の原則
37
38
先ほどの社員クラスの場合は、動作をクラスごとにわけるようにします。そうすることに
39
より各クラスの変更する理由をただ１つにすることができます。動作ごとにわけたクラス
40
が次の図になります。
41
42
3
オブジェクト指向設計の原則１＿単一責務の原則＆開放/閉鎖の原則
43
44
開放/閉鎖の原則(OCP: Open-Closed Principle)
45
46
簡単にいうとどんな原則？
47
48
ソフトウェアの要素（クラス、モジュール、関数など）は、拡張のために開かれていなけ
49
ればならないが、変更に対しては閉じていなければならない。
50
51
Software entities (classes, modules, functions, etc) should be open for extension,
52
but closed for modification.
53
54
具体的にいうと
55
「モジュール自体を変更することなく、モジュール環境を変更できなければならない」。
56
つまり仕様変更の発生や何らかによりプログラムを修正しなくてはいけない場合、プログ
57
ラムのソースコードは一切いじらずにプログラムのソースコードの追加で済ますというこ
58
とです。以下のクラスは開放/閉鎖の原則に違反しています。
59
60
このクラス設計で違反している部分は、Oracle だけにしか対応していないという部分です。
61
仕様変更により Oracle から MySQL や MSSQL に変更したいなど言われた場合、両方のク
62
ラスのソースを変更しなくてはいけません。また Oracle の環境ができていない状態で
63
Executor のテストをしたい場合、OracleAccessor のソースコードを修正しなくてはいけま
64
せん。ならどうすればよいのか？
4
オブジェクト指向設計の原則１＿単一責務の原則＆開放/閉鎖の原則
65
答えは、具象クラス(特定のデータベースクラス、ここでいう OracleAccessor)に依存するの
66
ではなく、抽象クラスやインターフェイスに依存するということです。次のクラス図を見
67
てください。先ほどの Executor クラスは OracleAccessor クラスに依存していましたが、
68
修正したクラス図の Executor クラスは抽象化された Accessor インターフェイスに依存し
69
ています。今後作成される予想のあるものを抽象化しておくのがミソです。
70
71
こうすることにより先ほどの仕様変更に柔軟に対応できます。次のクラス図を見てくださ
72
い。Oracle から MySQL や MSSQL に変更する場合、Oracle の環境ができていない状態で
73
テストする場合など、プログラムを一切変更せずに追加で済ませています。
74
75
この原則を使えば仕様に柔軟になる部分もありますが、固定される部分も出てきます。今
76
回固定される部分は、すべてのクラスに execute メソッドと connect メソッドを持たなけれ
77
ばならないということです。むやみに interface を変更するとすべての実装クラスを修正し
78
なくてはいけません。そのため interface の変更はできる限りしてはいけません。interface
79
(または抽象クラス)の設計は慎重にということです。
5
オブジェクト指向設計の原則１＿単一責務の原則＆開放/閉鎖の原則
80
81
用語集(wikipedia)
82
・デザインパターン：過去のソフトウェア設計者が発見し編み出した設計ノウハウ
83
・Gof(Gang of Four; 4 人のギャングたち)：GoF は、エーリヒ・ガンマ、リチャード・ヘル
84
ム、ラルフ・ジョンソン、ジョン・ブリシディースの 4 人。有名なパターンは 23 種類ある
85
・SAX(Simple API for XML)：XML 文書をアプリケーションソフトウェアから利用するた
86
めの API
87
・DOM(Document Object Model)：W3C から勧告されている HTML 文書や XML 文書を
88
アプリケーションから利用するための API
89
・UML(Unified Modeling Language)：ソフトウェア工学におけるオブジェクトモデリング
90
のために標準化された仕様記述言語
91
・payroll：一定の期間内に、企業の従業員に支払われた給与の総額
92
93
参考文献
94
Java プログラマーのための UML
95
アジャイルソフトウェア開発の奥義
96
http://www.objectmentor.com/で入手可能
6

Download Report