1

私はケースを持っています: There is はSomeNode、さまざまな基本部分で構成されています: いくつかのタイプのA,B,C. SomeNodeのインスタンスを別の に変換する変換関数もありますSomeNode。

ただし、 に加えてSomeNode、 にいくつかの他の部分が追加される可能性があるため、 の 4 番目の部分としてA,B,C存在する可能性があります。したがって、変換関数のインターフェースも、新しく追加された component に応じて変更する必要があるかもしれませんが、同じロジックが共有されている可能性があります。DSomeNodeSomeNode

それでは、抽象化するのに適した設計SomeNodeと、拡張性を高めるためのその変換機能は何ですか? 特性を使用していますか？どうやって？いくつかのインスピレーションの例? ありがとう、

4

3 に答える 3

2

モジュール性を管理するには、Cake パターン (別名 Bakery of Doom パターン) を確認してください。このトピックに関する興味深い記事がいくつかあります。

変換と特性を管理する場合、Scala コンパイラーは私が考えることができる最良の例です。

于 2012-11-03T20:57:27.940 に答える
1

何かが足りないのかもしれませんが、継承を探していませんか?

class SomeNode(val a: Int, val b: String, val c: Char)

class SpecialNode(from: SomeNode, val d: List[Int]) extends 
         SomeNode(from.a, from.b, from.c)

SpecialNodeのフィールドを共有しSomeNode、新しいフィールドを追加しdます。変換は次のようになります (もちろん、より複雑になる可能性があります。

def transform(node: SomeNode) = new SpecialNode(node, Nil)
于 2012-11-03T20:33:55.077 に答える
1

私の初心者のアイデンティティを示すことを犠牲にしてこれを書くことをためらっていますが、質問で使用されているキーワードに基づいて、「OOPの基礎」が求められているように思えます.

「簡単な拡張性をサポートするために、データとコントロールをどのように抽象化するか?」(一般化)

「さまざまな基本部分で構成される SomeNode があります:」 (集約)

「SomeNode のインスタンスを別の SomeNode に変換する変換関数もあります。」(多型)

「ただし、A、B、C に加えて、いくつかの他の部分が SomeNode に追加される可能性があります。関数のインターフェイスも、新しく追加されたコンポーネント SomeNode に応じて変更する必要があるかもしれませんが、いくつかの同じロジックが共有される可能性があります。」（インターフェース）

「それでは、SomeNode とその変換機能を抽象化して簡単に拡張できるようにするには、どのような設計がよいのでしょうか?」（継承）

質問の私の解釈に基づいて、SOLID 設計原則 http://www.youtube.com/watch?NR=1&v=05jVWgKZ6MY&feature=endscreenを調査することをお勧めします

于 2012-11-03T21:00:55.173 に答える