Scalaのケースオブジェクト汚染

Question

私は下記の;-)

両方のクラスを説明してみましょうここでの問題は、とは、名前空間の分離がないのでADMINがあいまいであるということである

RoleGroup.scala 
abstract class RoleGroup 
case object ADMIN extends RoleGroup 
case object MEMBER extends RoleGroup 

MailSender.scala 
abstract class MailSender 
case object ADMIN extends MailSender 
case object STAFF extends MailSender 
case object ACCOUNTANT extends MailSender 

パッケージcom.company.fooでありますケースのオブジェクト。 1つのパッケージにつき1つのユニークな名前のケースオブジェクトしか存在しないようです。

私は、関数a la mailADMIN、roleADMINなどに基づいてケースオブジェクトの名前を付けることができます。または、ちょうど適切な列挙型を作成し、ケースオブジェクトを忘れるべきですか？または、他のアプローチをとる？ MailSenderため

object RoleGroup { 
    sealed trait RoleGroup 
    case object ADMIN extends RoleGroup 
    case object MEMBER extends Rolegroup 
} 

と同様：

Answer 1

次のような何かを行うことができます。そして、あなたは一つだけを使用している状況で、あなたはimport MailSender._または万力その逆を行うことができますが、使用しているとき、あなたはRoleGroup.ADMINとしてそれらを参照してください両方、など

あなたが列挙型を、このアプローチを取るか、または使用するかどうか、主にどのように依存しますあなたはそれらを使うつもりです。このaproachでは、各 "列挙型"は型ですが、列挙型では各列挙型は値です。コンパイラはあなたのマッチが網羅的であるかどうかをチェックできるので、前者はパターンマッチングに適しています。後者は、シリアライゼーションの作業の方が優れています（IMO）。

Answer 2

他の場所のように、ここでは列挙型は必要ありません。適切な名前空間が必要です。また、スカラ座の強みをご提供しながら、この方法は非常に多く、Javaの列挙型を思い出させます、それを使用して

sealed abstract class RoleGroup 
object RoleGroup { 
    case object Admin extends RoleGroup 
    case object Member extends RoleGroup 
    // also just in case 
    sealed case class SomeParameterizedGroup (
    param1: Any, 
    param2: Int 
) extends RoleGroup 
} 

：私はコンパニオンオブジェクトのアプローチが最もbenefitialであることがわかり

def foo (roleGroup: RoleGroup) = 
    roleGroup match { 
    case RoleGroup.Admin => 
    case RoleGroup.SomeParameterizedGroup(param1, param2) => 
    } 

ますのでご注意くださいダンの解答では、roleGroupのタイプはRoleGroup.RoleGroupであり、これはちょっと不自然だと感じています。また、大文字の名前はScalaのスタイル規則に違反していることに注意してください。