asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

デザイン:設計順序の原則

更新履歴:
2008.02.27 - 読みやすいように&議論を少し修正。

 疑問:実現すべき機能要求の集合が与えられたとして、どの順番でそれらの機能を設計・実装していくのが適切なのか?

疑問


少し前に気づいて疑問に思ったことだけど、実現すべき機能要求の集合が与えられたとして、

 (1)どんな順番で機能を設計・実装していくのがいいんだろうか?

 (2)順番は最終的な設計・実装結果に影響を与えないのだろうか?

ここでは、簡単のために機能的な要求だけを考えてる。非機能要求の考慮は保留。

議論


さて、自分自身に問い合わせてみたところ、少なくとも一つの原則に従って(従おうとして)設計・実装していることに気づいた。それは、抽象がなるべくできあがるような順番で機能を設計・実装しようとしている、ということ。

もっと具体的に言えば、ある機能AとBを設計・実装することで、抽象的なモジュール(たとえば抽象クラスやインタフェース)が出来るような順番。

たとえば、ゲームを作っているとし、次のような機能要求集合が与えられたとする。

 (1)キーボードによる操作ができること
 (2)マウスによる操作ができること
 (3)ゲームコンフィグができること。
 (4)ゲームデータがセーブできること
 (5)ゲームデータがロードできること

とすると、順番としては、たとえば次のようなものを選ぼうとする傾向があった。

 (A) (1)->(2)
 (B) (2)->(1)

これは、1と2がどちらも操作に関わる機能であるため、モジュール(クラス)として実現したときに共通の特性を持つ抽象(抽象クラスや interface)ができる可能性がある、という理由から。つまり、

 (a) コードの重複や共通のインタフェースができるだろうということ。

 (b) そして、操作に関わる機能を実現したモジュールを使うモジュールは、抽象を通して依存すべき、という原則の点から。

AとBのどっちを優先するかは機能の優先順位によるけれど、どちらもある一定の期間中に実現できればいいとするなら、AとBの順番は気にしない。

もちろん、個々の要求が独立しているとは限らないので[2]、実現の順序がほとんど決まってしまう場合もある。たとえば、機能Aを実現する前に機能Bができていなければならないなら、B->Aの順番で実現するのが普通だと思う。ただし、AとBの間にインタフェースI(もしくはデザインルール[3])を導入するなら、AとBは独立に実現できる可能性もある。


今まで考えたことがなかったので、読み逃しているかもしれないけど、僕が知る限り、機能の設計・実装の順序について議論している本はないように思える。

設計の原則はある。たとえば「アジャイルソフトウェア開発の奥義」では、次のようなオブジェクト指向における設計原則を解説している(わざわざ英語で書いてるのは、邦訳を持ってないため。


・The Single Responsibility Principle - A class should have only one reason to change.

・The Open-Closed Principle - Software entities (classes, modulues, functions, etc.) should be open for extension, but closed for modification.

・The Liskov Substitution Principle - Subtype must be substitutable for their base types.

・The Dependency Inversion Principle - Abstraction should be not depend upon details. Details should depend upon abstractions.

・The Interface Segregation Principle - Client should not be forced to depend upon methods that they do not use. Interfaces belong to clients, not to hierarchies.

・The Release-Reuse Equivalenct Principle - The granule of reuse is the granule of release.

・The Common Closure Principle - The classes in a package should be closed together against the same kinds of changes. A change that affects a closed package affects all the classes in that package and no other packages.

・The Common Reuse Principle - The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

・The Acyclic Dependencies Principle -
Allow no cycles in the package dependency graph.

・The Stable Dpendencies Principle - Depend in the directions of stability.

・The Stable Abstractions Principle - A package should be abstract as it is stable.



上記以外の設計原則としては「Refactoring in Large Software Projects 」で紹介されているのがある(上記と被る原則は省略)。

・Don't Repeat Yourself - Do not write the same or similar code more than once.

・Speaking Code Principle -
The code should communicate its purpose. Comments in the code could indicate that the code communicate its purpose insufficiently.

・Tell, Don't Ask -
Don't ask an object about an object, but tell it what to do.




でもこれらの設計原則は、プロダクトとしての設計、つまり具体的にはモジュール、プログラム、コードの構造が備えているべき特性や品質の原則に思える。

もしかすると、プロセスの結果としてのプロダクトに関する原則は、プロセスに関する原則との表と裏の関係かもしれない。

それでも、プロセスとしての設計原則を明示的に表しておくのは、効果的であると思う。

たとえば、一つの具体的なものから抽象的なものを考えるよりも、二つの具体的なものから抽象的なものを考える方が易しい。これを設計プロセスの(仮の)原則として言うなら、こんな感じ:

 抽象が作りやすくなるような順番で、機能を設計・実装せよ。


参考


[1] ロバート・C・マーチン, アジャイルソフトウェア開発の奥義

[2] アラン・M・デービス, 成功する要求仕様 失敗する要求仕様

[3] キム・クラーク,カーリス・ボールドウィン, デザイン・ルール―モジュール化パワー

番外編


今回の記事の内容に直接関わるかどうかは分からないけど、Christopher Alexander の「The Nature of Order」のBook 2では、順番についての次の記述がある。


4. VITAL IMPORTANCE OF THE "RIGHT" SEQUENCE

In architecture, as in other things, the importance of sequence is both simple, and potentially shocking. Even when there are only two steps to be token, the order in which they are done may be all-important. And it may be highly surprising.

Consider for example the process of laying out a house on a lot.

"Common sense" says that you should first place the house, and then place the garden, This is common sense; but it is wrong. To make the environment and the formation of house garden together come out right, you have to reverse the order of these two operations, as follows:
1. First: Locate the garden in the best and most beutiful place.
2. Then: Locate the house so that i helps and supports the garden.

This example is fascinating because it illustrate the enormous significance of sequence. If you place the house first, you are stuck with the leftovers as places for the garden. In all likelihood the garden will not become a pleasant place. Possitive space will amost certainly be violated. So will view, smell, noise. But if you locate the garden first and then place the house volume in a way which supports the wholeness of the garden, the garden will come out better and so will the house.

Of the two available sequence for these two operations, one sequence is wrong, and ohe is right (90% of the time). The sequence which is wrong, is correct according to conventional wisdom, and probably considered obviouse by millions of people. The one which is right (and which gives you insight, makes things more understandable, and gets wholesome results), flies in the face of common sense, and would be rejected by nine out of ten people who first hear it. Yet it is the right answer.

Few examples explain the enormouse power and siginificance of sequences more vividly. And as you can imagine, if the sequence -- the order of steps -- is significant when dealing with only two operations, how much more siginificant it will be when dealing with ten, or twenty, or fifty steps. There the chance of getting the sequence right by accident, is extremely small.



スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/96-1a44d544
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。