■[プログラマ97]単一責任原則

The Single Responsibility Principle

Uncle Bob

単一責任原則

ロバート・C・マーティン

どういうこと？

良いデザインの基本原則を、強いて１つ選ぶとすれば、それは「単一責任原則（SRP：Single Responsibility Principle）」です。

変更する理由が同じものは集める、変更する理由が違うものは分ける。

１つのサブシステムやモジュール、クラス、関数などに、変更する理由が2つ以上あるようではいけない、ということです。

たとえば？

ルール、レポート、データベースに関わるメソッドを持つクラスがあります。

public class Employee {
	// ルール：給与計算
	public Money calculatePay()...
	// レポート：作業時間報告書
	public String reportHours()...
	// データベース：保管
	public void save()...
}

３つのメソッドが１つのクラスに集められていることを特に問題と思わず、むしろ望ましいと思うプログラマもいるかもしれません。結局のところ、クラスというのは、同じ変数を操作するメソッドの集まりなのだから、と考えるわけです。

しかし、上のクラスが問題なのは、３つのメソッドがまったく違った理由によって変更される可能性があるということです。

calculatePayメソッドは、給与計算に関わるビジネスルールが変わる度に、reportHoursメソッドは、レポートのフォーマットが変わる度に、saveメソッドは、DBAがデータベーススキーマを変更する度に、変更を加える必要があります。３つも変更理由があるEmployeeクラスは、非常に不安定な存在となってしまいます。

さらに重要なのは、Employeeに依存するクラスがすべて、Employeeの変更に影響されるということです。Employeeの変更波及範囲が大きくなっているのです。

どうすれば？

良いシステムデザインとは、システムのコンポーネントがそれぞれ独立してデプロイできるようになっているデザインです。独立してデプロイできるというのは、あるコンポーネントに変更を加えたからといって、別のコンポーネントの再デプロイは不要であるという意味です。

しかしEmployeeが、別のコンポーネントの数多くのクラスによって利用されるのだとしたら、Employeeに変更を加える度に、他のコンポーネントの再デプロイが必要になります。それだとコンポーネントデザインの大きな利点が失われてしまいます。

よって、以下のようにクラスを分割します。

public class Employee {
	public Money calculatePay()...
}

public class EmployeeReporter {
	public String reportHours(Employee e)...
}

public class EmployeeRepository {
	public void save(Employee e)...
}

関連

• 単一責任の原則（SRP）
• オープン・クローズドの原則（OCP）
  • Employeeの変更波及を抑えるには、さらにOCPを適用します。

Permalink | コメント(0) | トラックバック(0) | 07:04

■[アーキテクト97]怒れるアーキテクトとしてビジネスと対立するな

The Business Vs. The Angry Architect

Chad LaVigne

怒れるアーキテクトとしてビジネスと対立するな

チャド・ラヴィーニュ

どういうこと？

自己過信が度をすぎると、ビジネスの人々に尊大な態度を取るようになります。

自分の知識を過信して、話を聞くよりも話をすることに夢中なります。さらに、「技術に優れた理解を持つ自分に、あえて反論を挑む愚かな人々」と相手を見下し、皮肉を言い、短気になり、そして怒るのです。

そんなことをすれば、アーキテクトとしてのキャリアは終了です。

どうして？

ビジネスは、アーキテクトの存在理由です。この事実を見失ってはなりません。アーキテクトはビジネスにサービスを提供するために生きているのであって、その逆ではないのです。

どうすれば？

ビジネス側の話を聞き、理解することは、問題を解決するための重要なスキルです。

ビジネスドメインのエキスパートに、敬意を示さなければなりません。近づきにくい人間だと思われてはいけないのです。「自分が賢いので、誰も自分より価値のあることを言えない」という態度を取れば、そのうち避けられるようになってしまいます。それは、コミュニケーション崩壊のきっかけを作り、自分で自分のチームを壊しているということです。

ビジネスの進め方に意見してもかまいませんが、いやみな感じで話して人目を引こうとする「不機嫌な天才」を演じてはなりません。相手は本当にうんざりしてしまいます。優れたアーキテクトになるために大切なことは、仕事に情熱を傾けることです。さまざまな怒りで熱くなりすぎることではありません。

意見の不一致を受け入れて仕事を進めることを覚えまます。どのような方法であれ、ビジネスとよい関係を結び、自分のエゴで関係を損ねないようにすることです。そうすれば、生産性の高いアーキテクトになれるはずです。

関連

• 

  怒らない技術 (フォレスト2545新書)

  • 作者: 嶋津良智
  • 出版社/メーカー: フォレスト出版
  • 発売日: 2010/07/07
  • メディア: 新書
  • 購入: 6人 クリック: 58回
  • この商品を含むブログ (43件) を見る
  • スマナサーラさんの本（「怒らないこと―役立つ初期仏教法話〈1〉 (サンガ新書)」「怒らないこと 2―役立つ初期仏教法話〈11〉 (サンガ新書)」）で怒ることの無意味さを理解し（Why）、この本で実践します(How)。

Permalink | コメント(0) | トラックバック(0) | 07:04