3

「子の可変引数を受け入れるように構築し、コードの繰り返しなしでいくつかの子の検査機能を公開するデータベースオブジェクトの抽象コンテナをモデル化する」と言われました。

これは、「子の数を数える」、「識別子で検索する」などのヒントになります。

簡単にするために、以下のコードには基本抽象 DatabaseObject 型 (つまり名前) から 1 つのフィールドしかありませんが、実際のコードには「識別子」や複雑なメタデータ検索ギミックなどがあります。

このアイデアは確かに便利ですが、コードを書き始めたものを見るだけで吐き気がします。この道を進むと、もつれのフランケンシュタインになるでしょう。これをまともなJavaにする方法はありますか? 参照する設計パターンはありますか? （コンポジットが思い浮かびます…）

前提: 共有される実際の機能は有用であり、潜在的なネスト可能な型 (スキーマにはテーブルがあり、テーブルには列があり、CompositeIndex(es) にはサブインデックスがあるなど)、特に識別子ルックアップに実際に適用できます...

...しかし、「もっと良い方法があるはずです」。「そんなコードを書くときは、自分の顔を平手打ちする」という声が私の中で感じられます。

ヘルプ ：）

public abstract class DatabaseContainerObject<ChildType extends DatabaseObject>
    extends DatabaseObject {
  protected List<ChildType> children;
  public DatabaseContainerObject(String name, ChildType... children) {
    super(name);
    this.children = new ArrayList<ChildType>(children.length);
    this.children.addAll(Arrays.asList(children));
  }
  protected List<ChildType> getChildren() {
    return Collections.unmodifiableList(children);
  }
  ... count ...
  ... find ...
  ... sort ...
  ... remove ...
  ...
}
4

3 に答える 3

1

Strategy パターンについて考えてみてください (http://en.wikipedia.org/wiki/Strategy_pattern)。原因：

  1. データとデータ操作を切り離します。
  2. 実行時にアルゴリズム（「子の数」、「識別子による検索」）を変更できます。

私は、それは次のようなものだと思います：

public abstract class DatabaseContainerObject<ChildType extends DatabaseObject>
extends DatabaseObject {

    protected List<ChildType> children;

    private DataOperator dataOperator;

    public Object find(){
         return dataOperator.find(children);
    }

}

public interface DataOperator{
     public <ChildType extends DatabaseObject> find(List<ChildType> childList);
}

public Class GeneralDataOperator extends DataOperator{
    public <ChildType> find(List<ChildType> childList){
        //implements find; 
    }
}

次に、依存性注入を使用できます。

于 2012-06-09T15:50:24.460 に答える
0

Composite はすぐに頭に浮かびますが、Decorator パターンも調査する必要があります。

Find は明らかに再帰的になりますが、たとえば Count はリーフ オブジェクトに非常に限定されており、すべての種類のノードでほぼ同じです。

于 2012-06-09T14:42:28.697 に答える