社内発表 2010/09/27

1. HOWTO
よいデザイン
Hiroki Yagita
2010/09/27
YSH

2. ※

3. ドメイン = ソフトウェア

4. デザイン = 設計

5. 質問は適時で

6. よいデザインの原則

7. 1.定石にもとづく

8. 2.疎結合

9. 3.高凝集

10. 4.Design by contract

11. 5.高いテスト容易性

12. 6.以降もたくさんある

13. 今日は1.だけ

14. 1.定石にもとづく

15. ソフトウェア開発のある部分を
切り出すと一定のパターンには
まることが非常に多い

16. Example #1
グラフィカルユーザーインターフェイス
↓
イベントドリブン
ダブルフリップ

17. Example #2
一度に複数を同時実行
↓
マルチスレッド
同期オブジェクト

18. Example #3
様々な外部記憶装置を一様に扱う
↓
ファイルシステム
ストリーム

19. ◎
既知のパターンをできるかぎり多く押さえ
ておくことが、よいソフトウェアを開発でき
るか否かの鍵となる

20. ×
パターンに基づかずに開発したソフトウェ
アは、パターンにはまっていないが故に学
習コストが高く、見通しが悪くなる

21. パターン概要

22. アーキテクチャパターン
デザインパターン
イディオム

23. アーキテクチャパターン
デザインパターン
イディオム

24. イディオム

25. ソフトウェア工学においてアルゴリズムや
プログラミングのノウハウ、チップを集めた
もの
-- http://ja.wikipedia.org/wiki/イディオム_(曖昧さ回避)

26. Example #1 Ruby
obj ||= {}
unless obj
obj = {}
end

27. Example #2 Ruby
a, b = b, a
c = a
a = b
b = c

28. Example #3 C
void usage() { /* … */ }

29. Example #4 C
while ((c = getc(f)) != EOF) {
/* … */
}

30. Example #5 C++
class NonCopyable {
private:
NonCopyable(const NonCopyable &);
NonCopyable &operator=(const NonCopyable &);
};

31. ◎
知っている人は流れる水のごとく意味を理
解できるため、コードリーディング・コードラ
イティングスピードが圧倒的に速くなる

32. ×
イディオムにもとづかずに開発したソフト
ウェアは、イディオムにはまっていないが
故に学習コストが高く、見通しが悪くなる

33. イディオム本

34. 1. Code Reading
http://amzn.to/adcMvY
2. リファクタリング
http://amzn.to/M3UvT
3. ケント・ベックのSmalltalkベストプラクティス・パ
ターン―シンプル・デザインへの宝石集
http://amzn.to/aeEBdL

35. デザインパターン

36. コンピュータのプログラミングで、素人と達人の
間ではびっくりするほどの生産性の差があるが、
その差はかなりの部分が経験の違いからきて
いる。達人は、さまざまな難局を、何度も何度も
耐え忍んで乗り切ってきている。そのような達
人たちが同じ問題に取り組んだ場合、典型的に
はみな同じパターンの解決策にたどり着くのだ
が、これがデザインパターンである (GoF)。
-- http://ja.wikipedia.org/wiki/デザインパターン(ソフトウェア)

37. デザインパターンをものにする
プロセス

38. 1.本を読んで覚える
2.実際に使ってみる
3.パターン病に罹患する
4.パターン病から回復する
5.パターンを理解する

39. Example #1 Template Method(C++)
class FuncA { class FuncInterface {
public: public:
void func() { void func() {
// 前処理 // 前処理
// 固有処理1 specific_func();
// 後処理 // 後処理
} }
}; protected:
virtual void specific_func() = 0;
class FuncB { };
public:
void func() { class FuncA : public FuncInterface {
// 前処理 protected:
// 固有処理2 virtual void specific_func() {
// 後処理 // 固有処理1
} }
}; };
class FuncB : public FuncInterface {
protected:
virtual void specific_func() {
// 固有処理2
}
};
適用前 適用後

40. ◎
デザインパターンを押さえることで設計上
の典型的な問題を簡単に解決することが
出来るようになる。また、すべてのデザイ
ンパターンには名前がついているため、設
計者同士での議論を加速することが可能
となる。

41. ×
デザインパターンにもとづかずに開発した
ソフトウェアは、デザインパターンにはまっ
ていないが故に学習コストが高く、見通し
が悪くなる

42. デザインパターン本

43. 1. オブジェクト指向における再利用のためのデザインパターン
http://amzn.to/80alJI
2. パターン指向リファクタリング入門
http://amzn.to/dB23ad
3. プログラムデザインのためのパターン言語
http://amzn.to/8ipKvr

44. アーキテクチャパターン

45. アーキテクチャパターンは、ソフトウェアシステムの基礎的な構
造組織化スキーマ(structural organization schema)を
表現するものである。アーキテクチャパターンによって、あらか
じめ定義されているサブシステムの集合が与えられ、その責務
が決定される。パターンには、サブシステム間の関係を組織化
するルールとガイドラインが含まれる。
-- PATTERN-ORIENTED SOFTWARE ARCHITECTURE

46. Example #1 Layers
OSI 参照モデル

47. Example #1 Layers
Android architecture

48. Example #2 Model-View-Controller
Smalltalk-80 MVC

49. Example #2 Model-View-Controller
Ruby on Rails MVC

50. ◎
アーキテクチャパターンを押さえることでシ
ステムがどのような基本構造を持っている
かを明確に示すことができ、また、明確に
理解することができるようになる。

51. ×
アーキテクチャパターンにもとづかずに開
発したソフトウェアは、アーキテクチャパ
ターンにはまっていないが故に学習コスト
が高く、見通しが悪くなる

52. アーキテクチャパターン本

53. 1. ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
http://amzn.to/9TiAiR
2. エンタープライズアプリケーションアーキテクチャパターン
http://amzn.to/d0A1v
3. ビューティフルアーキテクチャ
http://amzn.to/4Ydjtt

54. 結論

55. 定石を会得せよ

56. おわり