Application Design 勉強会 #2

Application Application Design 勉強会 #2

Transcript

1. Application Design 勉強会 #2

   Wed Jun 26
   Kazuki Chigita
   

   View Slide

2. 第7章

   アジャイル設計

   

   View Slide

3. アジャイル開発の考え

   - アジャイル開発での全体像はソフトウェアと共に

   展開していく．

   

   - 先を見越してデータベースの設計はしないし，将来の要求に
   時間を掛けない．

   

   - 各イテレーションで「今」を最良の構造にし，常に「今」と同じ
   レベルの品質を保つ．

   

   View Slide

4. アジャイル設計ってなに？

   - アジャイル開発で用いる 設計 手法

   - つまり，どういうソースコードであるべきかが

   「設計」だ (著者談)

   

   

   - なぜアジャイル設計をするのか？

   - ソフトウェアはアジャイル開発のイテレーションを

   通して変化し続ける．

   - これに追従して設計をしないと「悪臭」がする．

   - 「悪臭」がすると，保守がしづらくなったり，機能追加に多大
   な工数がかかったりする．

   

   UMLダイアグラムのような抽象
   的に表現する技法での

   設計ではなく，これを具体化した

   ソースコード自身のこと．

   だから，設計をしなければならない．
   

   View Slide

5. 悪臭の例

   1. 硬さ 

   変更しにくいシステム．1つの変更のためにそれと依存関係に

   あるモジュールが芋づる式に変更点があらわれること．

   2. もろさ

   1つの変更によって，概念的に関連のない箇所までもが壊れて

   しまうシステム．

   3. 移植性のなさ

   他のシステムで利用価値のある部分をモジュールとして切り出すことが
   難しい状態．

   4. 扱いにくさ

   ソフトウェアの扱いにくさ，開発環境の扱いにくさ．

   5. 不必要な複雑さ

   設計時に不必要な仕様を取り込んでいる(アジャイル開発の考えに反し
   ている)

   6. 不必要な繰り返し

   別モジュールからコピペしてきたものを含んでいる．

   抽象化すべき．

   7. 不透明さ

   わかりにくいモジュールが存在する状態．

   

   View Slide

6. 何がソフトウェアを腐敗させるのか？

   - 仕様変更に追従できなくなったときにソフトウェアが

   腐る．

   - 仕様変更に追従できない→設計に問題がある→

   アジャイル開発に耐えうる設計やプラクティスを実践するべき

   

   

   - アジャイルチームはソフトウェアの腐敗を許すな．

   - じゃあどうすれば？→クリーンな設計やプラクティスを実践す
   るべき．

   - クリーンな設計やプラクティスを以降の章で紹介．

   

   

   View Slide

7. 第8章

   単一責任の原則(SRP)

   

   View Slide

8. 単一責任の原則

   (SRP : Single Responsibility Principle)

   - SOLID原則の一角を成す．

   

   - 日本語での説明

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

   - 本には1つ以上と書いてあるけど，多分違う．

   

   

   View Slide

9. Rectangleクラスの例

   - Geometry applicationが演算処理のためにRectangleクラスを
   参照する．

   - Graphical ApplicationはGUIへの描画のためにRectangleクラ
   スを参照する．

   

   Geometry
   Application
   GUI
   Graphical
   Application
   Rectangle
   +draw()
   +area(): double
   

   View Slide

10. SRP違反の改善

    - この状況下でのRectangleの役割

    1. 数学的なモデルを提供する役割

    2. GUIで四角形を塗りつぶす役割

    

    - 悪臭シリーズでいうところの扱いにくさ

    - Geometry applicationが不必要にGUIを含む構図に

    なっている．

    - GUI都合で表示するものが変わったときに無関係なGeometry
    Applicationも変更の必要が生まれる．

    

    - 解決策は，演算部分を切り出す(抽象化してinterfaceを切り出
    す操作と言える)

    

    Geometry
    Application
    GUI
    Graphical
    Application
    Rectangle
    +draw()
    +area(): double
    

    View Slide

11. SRP違反の改善

    Geometry
    Application
    GUI
    Graphical
    Application
    Rectangle
    +draw()
    +area(): double
    Geometry
    Application
    GUI
    Graphical
    Application
    Rectangle
    +draw()
    Geometric
    Rectangle
    +area(): double
    

    View Slide

12. 単一責任の原則の「責任」とはなにか？

    - 「責任 = 役割 = 変更理由」と定義している．

    

    - クラスの変更理由は1であるべき <=> クラスの変更理由が2つ
    以上ある場合そのクラスには2つ以上の役割がある．

    

    

    View Slide

13. 単一責任の原則の適用を見極める

    - 役割が2つ以上あるときに分離するのが基本．

    

    - しかし，異なる役割ながら，必ず同時に変更が生じる役割は
    分離する必要なない． 

    <=> 複数の役割が結合する理由を持っている事がある．

    - 過剰な適用は設計を不必要に複雑にする．

    - これは他の原則でも不必要な適用は良くない．

    

    - 「変更の理由が変更の理由たるのは，"実際に"変更の理由
    が生じる場合だけ」

    

    

    View Slide

14. 第9章

    オープンクローズドの

    原則

    

    View Slide

15. オープンクローズドの原則

    (OCP : Open-Closed Principle)

    - 拡張に対して開かれている(Open)

    モジュールの振る舞いを拡張できる．

    追加の仕様要求がきてもモジュールに新たな振る舞いを

    追加することでその変更に対処できる．

    

    

    - 修正に対して閉じている(Closed)

    モジュールの振る舞いを修正しても，そのモジュールの

    ソースコードやバイナリは影響をうけない．

    

    これはなんか矛盾している概念に見えるがなんとかなる．

    

    View Slide

16. client-serverの例

    - Client，Serverともに具体的な実装を持っている．

    

    - Serverの実装が変更されるとClientも変更せざるを

    えない．(OCP違反)

    Client Server
    

    View Slide

17. 解決策1 : 抽象を利用することでOCPを実現(Strategy
    pattern)

    - 依存部分をinterfaceとして切り出す．

    

    - server abstractにしない理由→抽象クラスはそれを実装す
    る側より使う側のほうが関係が密接だから．

    

    - Serverの実装が変わってもClientは影響を受けない．

    Client
    <>
    Client Interface
    Server
    

    View Slide

18. 解決策1 : 抽象を利用することでOCPを実現(Strategy
    pattern)

    - 依存部分をinterfaceとして切り出す．

    

    - server abstractにしない理由→抽象クラスはそれを実装す
    る側より使う側のほうが関係が密接だから．

    

    - Serverの実装が変わってもClientは影響を受けない．

    Client
    <>
    Client Interface
    Server Piyo
    

    View Slide

19. 解決策2 : 抽象を利用することでOCPを実現(Template
    Method Pattern)

    - Policyクラス(方針クラス)は具体的な実装を持っている(一つ
    前のClientに対応)．

    と同時に，抽象メソッドを持っている．(Client interfaceに対応)

    

    - Policyクラスの抽象メソッドを実装する実装クラスが

    ある(Serverに対応)

    

    Policy
    + PolicyFunction()
    - ServiceFunction()
    Implementation
    - ServiceFunction()
    

    View Slide

20. OCPの実現

    - Strategy Pattern , Template Method Patternが

    典型的．

    

    - 汎用的な機能と，その機能の具体的な実装を明確に

    分離する役割を持つ．

    

    - 使い所 : 最も変更されるプログラム部分にだけ的を

    絞って抽象化を適用するように務める

    (早まった抽象をしないことも抽象を使うのと同等に

    重要なこと)

    

    

    View Slide

21. 参考資料

    - アジャイルソフトウェア開発の奥義

    - ロバート・C・マーチン

    - pp. 103 - 141

    

    View Slide