1

Scala を使用してlast.fmからのartist.getInfo呼び出しを解析しようとしています。scala の Xml API は非常に優れていますが、デザイン (およびおそらく個人的な趣向) について疑問があります。

現在、コンパニオン オブジェクトの XML からデータを解析し、次のようにクラスのコンストラクターに渡します。

class ArtistProfile (
                      name: String,
                      musicBrainzId: String,
                      url: String,
                      images: List[Image],
                      streamable: Boolean,
                      listeners: Int,
                      plays: Int,
                      similarArtists:List[SimpleArtist]) 

object ArtistProfile {

def apply(xml: NodeSeq) : ArtistProfile = {
  val root = xml
  val name = SimpleArtist.extractName(root);
  val url = SimpleArtist.extractUrl(root);

  val musicBrainzId = root \ "musicBrainzId" text
  val images:List[Image] = Image.findAllIn(root)
  val streamable = (root \ "streamable" text) eq ("1")

  val listeners = (root \ "stats" \ "listeners").text.toInt
  val plays = (root \ "stats" \ "plays").text.toInt

  new ArtistProfile(
    name,
    url,
    musicBrainzId,
    images,
    streamable,
    listeners,
    plays,
    SimpleArtist.findAllIn(xml \ "similar"))
  }
}

ご覧のとおり、これらは多数のパラメーターです。私の質問は、xml NodeSeq を ArtistProfile コンストラクターに渡す方が (scala の機能の点で) より良いスタイルになるかどうかです。そのため、クラス自体がコンパニオン オブジェクトではなく解析を引き継ぎます。

独自の last.fm scala ライブラリ (scala の入門プロジェクトとして) を作成しようとしており、すべてのオブジェクトで一貫性を保ちたいため、これを求めています。

  1. 通話には、すべての人が必要としない可能性のあるデータがいくつかあります。2 番目のアプローチでは、オブジェクト リストが大きくなる場合は遅延 val を使用し、それ以外の場合は通常の val を使用できます。プログラマにとっては、違いはありません。
  2. 一方、オブジェクトの作成に必要なデータの解析は、オブジェクト自体から分離されています (上記の例のように)。

問題へのより良いアプローチはどれですか？

4

1 に答える 1

4

これに対する白黒の答えがあるかどうかはわかりません。コンパニオン オブジェクトを必要とせずに、xml ノードからインスタンスを作成できるように、クラスに補助コンストラクターを配置することもできます。

ただし、ファクトリ パターンを優先する十分な理由があります。

  1. クラス ArtistProfile は、ユーザー コードに影響を与えることなく、そのフィールドまたはまったく新しいサブクラスに変更できます。
  2. JVM が最適化しないため、コンストラクターで実質的な処理を行うことはお勧めできません。
  3. たとえば、同じプロファイルが 2 回要求された場合、新しいインスタンスを返すのではなく、値をキャッシュできます。
  4. コンストラクターはオブジェクト指向の観点からはあまり意味がありません: オブジェクトはどのようにそれ自体を構築できるのでしょうか?
  5. これは Scala のコレクションとケース クラスの規則に従い、より簡潔に呼び出すことができます。

ファクトリ パターンの主な欠点 (プライマリ コンストラクターをプライベートにすると仮定) は、Effective Javaで説明されているように、ユーザーがサブクラスを作成できないことです。

それらをすべてコンパニオン オブジェクトに入れます。

于 2012-05-23T23:49:14.187 に答える