- - PR -
StateパターンでのInterfaceの使用について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-01-14 23:52
るぱんです。
お疲れ様です。 もはや終わったあと・・・と言うことで少し残念なのですが、 ココで疑問が湧いてきました。 便乗質問でゴメンナサイ。 皆さんの中で 「Interfaceと抽象クラスの使い分けの基準はどのへんか？」 と言うことが疑問として頭をよぎりました。 先に「実装を持たない抽象クラスは使わない」 と言うご指摘がありましたが、 何もStateパターンによらず、 Interfaceと抽象クラスの使い分けのポイントなどがありましたら 御教示願いたいと思います。 個人的なたたき台としての認識を示したいと思います。 Interface ：実装部分を考慮せずに設計段階でpublicメソッドでこういうのが 欲しい・・・と思ったときに使用 抽象クラス：実装部分迄考慮した際に汎化で搾り出したものに適用 個人的にInterfaceは設計で決めるために必要・・・ 抽象クラスにImplementの制約をつけてもいいのかな？と言う程度の認識です。 １．つまり、作る際には最初に下部のクラスは考慮せずにInterfaceで使用するメソッドを決めておく ２．そうすると、下部で汎化を意識したときにInterfaceをImplementした抽象クラスを作り出してやる ３．２の項目で汎化がおきなければInterfaceで止めておく こんな認識でいます。 皆様の思うところを御教示願いたいと思います。 | ||||||||
|
投稿日時: 2005-01-15 00:17
私の場合、最初は役割をすべてInterfaceで定義します。
それから、定義したInterfaceのうちいくつか
については抽象クラスによる実装の提供を検討します。 たとえば、publicかつsealedなTemplate Methodを提供し、その中で protectedの仮想メソッドを呼び出すようにしておくことで スーパークラスで処理の大枠を強制しつつもサブクラスごとに 振る舞いを変えることができます。 また、C#やJavaは単一継承なので、必要以上に継承を使いたくないという 理由もあります。 | ||||||||
|
投稿日時: 2005-01-18 13:58
Ｍｉｃｋｙでございます。
若干乗り遅れ気味ですが、ご容赦ください。（＾＾；
更に、質問に対する質問の様になってしまい心苦しいのですが… 最近では最初から[Interface]ありきで分析・設計に取り組むのでしょうか？ 個人的な感覚としては[Interface]ってＶＢから発生してきた、 .NET特有のモノだという意識が強いんですよ。 ですから、自分が最初になんらかのクラス図にした時には [Interface]と言うキーワードは出てこないと思うんです。 ＧＯＦ本にしても、抽象クラスは出てきますが[Interface]は出てきませんよね？ このスレッドの本来の質問に対する回答の様に、 まず[Interface]なしでの設計−＞リファクタリングの結果として[Intereface]の使用 とか Ａｄａｐｔｅｒパターンの様に異なる機能のクラス同士に共通のインターフェース を与えたい場面が出てきた という流れの方が自然であると考えてしまうんです。 最初から「抽象クラス」vs「Interface」と言う図式は なにかモヤモヤと引っ掛かってしまうんですね。 ですので、この辺りのみなさんの見解とかも聞いてみたいと思った次第であります。 よろしくお願いします。 | ||||||||
|
投稿日時: 2005-01-18 14:36
るぱんです。
最近では・・・という事ではないです。 勝手に「お？こっちのが楽ではないか？」ってな感じで受け取っていると思って下さい。 設計工程では実装面を考慮せずに独立性を考慮するべきなんじゃなかろうかと・・・。 といったレベルでの話です。 実際に実装を考慮しない設計は意味が無いのですが、論理上では可能・・・って感じで捉えて、理想論的に話しています。 Gofのデザインパターンを確認しましたが、理論のほうはInterfaceになってませんか？ え〜と、話の齟齬をなくすために、具体化しましょう。 パターンはStrategyでいいのかな？State？ GofパターンでInterfaceではなくAbstractを使うパターンの収録されている本を 教えてください。 [編集] 結城 浩さんの 「デザインパターン入門」には StateおよびStrategy両方にInterfaceの記述がありました。 [/編集] よろしくお願いします。 [ メッセージ編集済み 編集者: るぱん 編集日時 2005-01-18 14:42 ] | ||||||||
|
投稿日時: 2005-01-18 15:59
Ｍｉｃｋｙでございます。
実は同じ方向へ行っているのに、微妙にずれているのかな？ とも思いつつ…（＾＾；
本は 「オブジェクト指向における再利用のための デザインパターン」 です。 で、特に、どのパターンという事ではなくと言う前提だったんです。 この本は、Ｃ＋＋メインなんですね。 なので[Interface]と言う概念自体存在しないと思われます（＾＾； （古い版だからかな…）
とすると、わたしなんかは最初の段階では、 「言語や環境に依存しない設計」を目指しつつも 「言語や環境に備わっている便利な機能もある程度加味しないと…」 というのの葛藤をいつも繰り広げてるわけなんですね。（＾＾； とすると、最初から[Interface]ってのを意識するか否か… 「はてどっち？」なんて考えたもので、前回の投稿に至ったわけなんですよ。 結局、参考にした「デザインパターンの本」が想定している 言語やら環境やらで解釈も若干変わってしまうと言う事なのでしょうかねぇ？ 只、「Stateパターン」に関してはその適用場面を考えると [Interface]が使える環境では、その方が適している様な気がしてきています。 P.S.− 別スレの件、具体化したいですねぇ（＾＾） | ||||||||
|
投稿日時: 2005-01-18 18:40
こんにちは、iStation です。 GofのCDによると、「抽象クラスを導入して、Interfaceを宣言する...」となっていました。状態変化に対応して変化するのがオブジェクトの振舞いのみの時はInterfaceで良いのでは？ Erich Gamma et al., "Design Patterns CD" (1997) _________________ IEEE-CSDP 2004-2007 | ||||||||
|
投稿日時: 2005-01-19 10:10
みなさん、こんにちは。中西です。
Interface が指し示しているものが、型としての Interface なのか、振る舞いの制約としての INTERFACE なのかを見極める必要があるように感じました。 まずは抽象に対する振る舞いの制約としての INTERFACE(型としてのInterfaceではありません) を意識することが重要で、Interface か抽象クラスかの選択は抽象を実現させる手段として実装レベル(言語に依存する部分でもあります)で考慮してもよいのではないかと思っています。 | ||||||||
|
投稿日時: 2005-01-19 11:27
みなさん、こんにちは。
とてもためになるお話ですね。勉強させていただいております。 私の場合ですが、単に、抽象化したいのがクラスであれば抽象クラス、単なる振る舞いに関する制約であればインタフェイス、という感じで使い分けています。 「State/Strategy パターンの部分だけ」見ると、或る振る舞いに関する制約が付けられれば十分なので、インタフェイスが適しているような気がします。 但し、実際の設計では、 「State/Strategy パターン」を使おう → じゃインタフェイスを使おう とはなりません。先ず (リファクタリングの結果としての) クラス設計があって、そこにおける抽象化すべきものがクラスなのか、振る舞いに関する制約なのかの判断があり、結果として「State/Strategy パターン」の形になるだけですから。 それから、実装上の問題として、State/Strategy パターンなどが対象としている関心事が、既存のクラス階層と直交する関心事であった場合は、抽象クラスでなくインタフェイスを使います。多重継承できませんから。 これは、「アスペクトの実装を便宜上 (言語の都合上) interface で」というイディオムといえるかと思います。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。