0

非常に典型的な使用例: オブジェクト (またはクラス) は、関連する型のいくつかの public val を宣言し、それらすべてを含むコレクションを返すアクセサーを宣言したいと考えています。

case class Ball(dia :Int)
object Balls {
    val tennis = Ball(7)
    val football = Ball(22)
    val basketball = Ball(24)
    val balls = Seq(tennis, football, basketball)
}

この例は明らかに DRY に違反しており、エラーが発生しやすくなっています。変更可能な状態を使用して非常に簡単に解決できます (暗黙のBuilder[Ball, Seq[Ball]]パラメーターをBallコンストラクターに追加するなど)。しかし、その解決策にも問題がないわけではありません。特に、解決策を一般化しようとしたり、すべてのクラスが宣言するクラス階層を作成しようとすると、一部の値では、変更可能な部分的な要約から最終的な不変の値に切り替えるタイミングが明確ではありません。

知的な練習として、そして好奇心から、私は純粋に機能的な変種を考え出そうとしましたが、あまり成功しませんでした. 私が思いついた最高のものは

object Balls {
    import shapeless.{::, HNil}

    val (balls @
            tennis ::football::basketball::HNil
        ) =
            Ball(7)::Ball(22)::Ball(24)::HNil
}

これは非常に優れていますが、ボールまたはその初期化子の数が少なくなると、管理できなくなります。有効な代替手段は、すべてを HMap に変更することですが、私は通常、パブリック API で形状のない依存関係を回避しようとします。おそらくscalaの継続で実行できるように思えますが、リセットブロックに対して宣言を非ローカルにする方法がわかりません。

編集：私が以前に強調しなかったこと、およびscala.Enumeration私のために仕事をしない理由は、実際のケースではオブジェクトが同一ではなく、実際には複合構造であり、コンストラクターが数行以上かかることです. したがって、最終的な型は同じかもしれませんが (または少なくとも詳細には興味がありません)、単純な列挙ではなく、読みやすさの理由から、宣言されたメンバー/キーの名前を次のようにできることが重要です。その定義と視覚的に簡単に結びつけることができます。したがって、ここでの形状のないソリューションと、提案されている形状のない Seq ベースのソリューションは、実際の識別子を間違えて間違った値に変更が加えられる、オフバイワン エラーの影響を非常に受けやすくなっています。

もちろん、実際のケースは現在、継承されたコンストラクター メソッドによって生成された値のシーケンスを維持することにより、scala.Enumeration と同様に実装されています。ただし、列挙型が行うすべての問題があり、実際のobject Balls初期化子の外側でコンストラクターを呼び出したり、条件付きブロックの値を破棄したりすることによるエラーの可能性が増幅されます。その上、これが純粋関数型言語でどのように解決されるのか非常に興味がありました。

ケーキを持って食べる方法はありますか？

4

2 に答える 2

0

機能的な解決策ではないため、私の質問に対する適切な回答ではありませんが、コレクションも担当するコンストラクター メソッドによって作成された値が「失われる」という小さな問題は、コレクターをunapplyメソッドに移動することで対処できます。

class Collector[T] {
    private[this] var seq :Seq[T]=Nil
    def items = seq
    def unapply(item :T) = synchronized { seq = item+:seq; Some(item) }
}

class Ball private (val dia :Int)

object Ball {
    val Ball = new Collector[Ball]
    implicit private def ball(dia :Int) = new Ball(dia)

    val Ball(basket) = 24
    val Ball(tennis) = 7
    val Ball(football) = 22
}

構文的にはこのソリューションを好みますが、最も単純なファクトリ メソッドと比較して、混乱要因を相殺するほどメリットが大きいとは思いません。

于 2016-10-05T19:55:48.870 に答える