Перечисление как значение элемента для моделирования в Scala?

Question

Предположим, что я перехватил сетевой трафик и измерил время, размер и тип (TCP, UDP, AppleTalk) каждого пакета. Ничто иное, как IP-адреса или данные, не измеряется и должно быть смоделировано. Статистика фильтрации и вычислений - вот что я имею в виду. Я не намерен расширять классы специализации для TCP, UDP, ... с дополнительной информацией или функциями. Я новичок в Scale и задаюсь вопросом, каков правильный путь.

С перечислений, как в C/C++:

object TransportType extends Enumeration { 
    type TransportType = Value 
    val TCP = Value("TCP") 
    val UDP = Value("UDP") 
    val AppleTalk = Value("AppleTalk") 

} 

class Packet(val time:int , val size:Int, val type:TransportType) 

val p1 = new Packet(0, 200, TransportType.UDP) 
val p2 = new Packet(1, 1000, TransportType.TCP) 

Или с чертами:

object TransportType { 
    trait TCP 
    trait UDP 
    trait AppleTalk 
} 

class Packet(val time:int , val size:Int) 

val p1 = new Packet(0, 200) with TransportType.UDP 
val p2 = new Packet(1, 1000) with TransportType.TCP 

В последнем случае, может быть пакеты без специального типа. Это невозможно в первом случае. Я не заинтересован в этих различиях моделирования. Интересно, целесообразно ли создавать многие черты/классы, как во втором решении, и использовать систему типов для кодирования атрибутов. Если второе решение является правильным, предположим, что у пакетов есть другой атрибут Origin. Было бы неплохо моделировать его следующим образом:

object Origin { 
    trait NA 
    trait SA 
    trait EU 
    trait Asia 
    trait Africa 
    trait Australia 
} 

val p1 = new Packet(0, 200) with TransportType.UDP with Origin.Asia 

Является ли второе решение правильным - решение Scala-tic?

Answer 1

Хороший общий подход (с большим количеством исключений, оговорок и особых случаев, как и все общие подходы), которые я бы рекомендовал, это посмотреть на это следующим образом: участники являются свойствами, а черты - поведением.

Если TCP пакет в модели ведет себя по-разному от УДФА (например, один имеют методы, а другие нет, или если есть функции, которые принимают один в качестве аргумента, а не другой и т.п.), должно быть признаком, в противном случае должно быть свойство (у вас все еще могут быть пакеты без «специального типа», если есть необходимость - просто сделайте свойство необязательным, поэтому это не имеет особого значения).