4

2 つの抽象ファクトリ パターンが必要な引用一致プログラムを作成しています。これらは 2 つのインターフェイスです。QuoteFactoryとModeFactory。ModeFactory はEasyModeとHardModeを切り替え、QuoteFactory はいくつかの異なるサブジェクト (つまり、 PoliticalQuotes、SportsQuotes ) の間で引用を選び出します。簡単に言えば、ユーザーはモードを選択します。EasyMode が選択された場合、ユーザーは引用を推測する必要がありますが、ユーザーが HardMode を選択した場合、ユーザーは誰が引用を言ったかを知らされてから推測する必要があるため、Quote の実装はモードと選択した引用符に応じて変化します。

これまでのところ、インターフェイスとして ModeFactory を作成し、それを EasyMode と HardMode に実装しましたが、別の抽象ファクトリ パターン (またはそれ以上) をこれらのモードに統合して、Quote を選択できるようにする必要があります。役立つ場合は、Quotes が定義されている Quote クラスも作成しました。

これらの抽象ファクトリの基本的な実装を考え出すのを手伝ってくれる人はいますか? これは私がこれまでに持っているものの概要ですが、なんとなく複雑になりすぎていると感じざるを得ません...

編集: 私が言いたいことを明確にするために: ユーザーがイージー モードを選択すると、引用の開始とその引用の作成者が提供されますが、ハード モードを選択すると、引用の開始のみが提供されます。例えば

イージーモード： 「…の力を感じた」ジョゼ・モウリーニョ

ハードモード 「……のパワーを感じた」

ハードモードでは、作成者は、ユーザーが引用の残りを推測するのを難しくすることはできません。また、これは学校の課題ではありません。私は Head First Design Patterns を読んでいて、学んだことをさまざまな状況に適用しようとしています (ピザの例の代わりに、QI (英国のテレビ番組) を読んだ後、Quote Guessing Game に取り組んでいます) ） 本。

public interface ModeFactory {
    public Mode retrieveMode(String s); 
}

public interface QuoteFactory {
    public Quote retrieveQuote(String s);
}
4

4 に答える 4

2

一歩下がって、何をしようとしているのかを言い換えることができますか？チャレンジをよく知らない人に説明する努力をすることで、解決策が有機的に浮かび上がることが時々あります。

あなたの説明から、あなたはあなたが本当にやりたいことから始めるのではなく、部分的な解決策（「私は抽象ファクトリパターンを使いたい」）から始めたようです（例えば、「私は提供する見積もりクラスを提供したい」フレーバー（政治、スポーツ）とモード（簡単、難しい）に応じて異なる引用符"）。

工場ではなく、列挙型のように感じます。{政治、スポーツ}の列挙型と、モード用の列挙型があります。

編集：これについてもう一度考えた後、おそらくそれは学校の課題（「抽象的なファクトリパターンを使用して....何とか何とか何とか」）であり、それがあなたがハーフソリューションから始めた理由です。

于 2009-03-28T21:37:56.580 に答える
2

あなたはおそらくここで設計しすぎています。まず最初に必要なのはQuoteクラスです。これにより、見積もりがカプセル化され、イージーモードとハードモードの両方に適切なアクセサー（ゲッター）が必要になります。次に、引用符のコレクションが必要です。これらがデータベースに保持されている場合は、見積もりの​​タイプを簡単に選択できます。

また、ModeFactoryは不要だと思います。2つのモードから選択するためだけにインターフェースが必要なのはなぜですか？状態フラグはより単純です。

于 2009-03-28T21:52:38.383 に答える
1

重要な概念である質問クラスが欠落しているように私には思えます。これはモードと見積もりの​​両方で構成されており、正しい質問を出し、答えが正しいかどうかを電話で教えてくれます。

public class Question
{
    public Question(Mode mode, Quote quote) { /* store these */ }

    public String getQuestion()
    {
        return quote.getQuote() + (mode == Mode.EASY ? quote.getAuthor() : "");
    }

    public boolean isCorrect(String answer)
    {
        return quote.getFullQuote().equals(answer);
    }
}

ここでの私の考えは、見積もり自体はモード間で実際には変更されておらず、見積もりの​​どの部分がユーザーに表示されるかだけです。このアプローチでは、誰でもどこでも使用できるQuoteオブジェクトの単一のリポジトリを持つことができます。質問は、ユーザーに適切な量の情報を表示し、ユーザーが適切な応答をするかどうかを決定する責任があります。

于 2009-03-28T21:54:20.550 に答える
1

あまり考えずに、デザインを維持しようとせずに、このようなものはどうですか（QuoteクラスにはgetText（）メソッドとgetAuthorメソッドがあると思います。また、getText（int numberOfWords）にして、方法を構成することもできます。与える引用の多く）：

public enum Mode 
{
    EASY,
    HARD,
}

public enum Category 
{
    SPORTS,
    POLITICS,
}

public abstract class QuoteFactory 
{
    public QuoteFactory getQuoteFactory(final Mode mode)
    {
        // return either the Hard or Easy QuoteFactory
    }

    public abstract Quoute getQuote(Category category)
}

class HardQuoteFactory
    extends QuoteFactory
{
    public Quote getQuote(final Category category)  
    {
         // ...
    }
}

class EasyQuoteFactory
    extends QuoteFactory
{
    public Quote getQuote(final Category category)  
    {
         // ...
    }
}
于 2009-03-28T21:58:22.693 に答える