Поместить метод в трейт или в класс case?

Начиная с версии Scala 3, у вас есть возможность использовать параметры черт. (точно так же, как классы имеют параметры), что в данном случае значительно упрощает задачу:

trait Z(x: String) { def minus: String = x }
case class A() extends Z("a")
case class B() extends Z("b")
A().minus // "a"
B().minus // "b"

Я бы выбрал первое.

Почему ? Просто для соблюдения принципа открытости/закрытости.

Действительно, если вы хотите добавить еще один подкласс, скажем, case class C, вам придется изменить суперчерту/суперкласс, чтобы вставить новое условие... некрасиво

Ваш сценарий похож на Java с шаблоном template/strategy против условного.

ОБНОВЛЕНИЕ:

В вашем последнем сценарии вы не можете избежать «дублирования» ввода. Действительно, тип параметра в Scala нельзя вывести.

Все же лучше иметь связные методы, чем смешивать все в одном методе, представляющем столько параметров, сколько ожидает объединение методов.

Просто представьте десять условий в вашем методе суперчерт. Что, если вы непреднамеренно измените поведение каждого из них? Каждое изменение будет сопряжено с риском, и модульные тесты суперпризнаков всегда должны запускаться каждый раз, когда вы его изменяете...

Более того, непреднамеренное изменение входного параметра (не ПОВЕДЕНИЯ) вовсе не «опасно». Почему? потому что компилятор скажет вам, что тип параметра/параметра больше не актуален. И если вы хотите изменить его и сделать то же самое для каждого подкласса... обратитесь к своей IDE, она любит рефакторинг подобных вещей одним щелчком мыши.

Как объясняется в этой ссылке:

Почему важен принцип открытого-закрытого:

Модульное тестирование не требуется.
Нет необходимости разбираться в исходном коде важного и огромного класса.
Поскольку код рисования перемещается в конкретные подклассы, снижается риск повлиять на старые функции при добавлении новых функций.

ОБНОВЛЕНИЕ 2:

Вот пример, избегающий дублирования входных данных, соответствующий вашим ожиданиям:

sealed trait Z { 
     def minus(word: Boolean): String = if(word) whenWord else whenNotWord
     def whenWord: String
     def whenNotWord: String             
  }

case class A() extends Z { def whenWord = "ant"; def whenNotWord = "a"}

Вывод типа спасибо :)

Лично я бы держался подальше от второго подхода. Каждый раз, когда вы добавляете новый подкласс Z, вы должны прикасаться к общему минусовому методу, потенциально подвергая риску поведение, связанное с существующими реализациями. При первом подходе добавление нового подкласса не оказывает потенциального побочного эффекта на существующие структуры. Здесь может быть немного принципа Открытости/Закрытости, и ваш второй подход может нарушить его.

Принцип Open/Closed может быть нарушен при обоих подходах. Они ортогональны друг другу. Первый позволяет легко добавлять новый тип и реализовывать необходимые методы, он нарушает принцип Open/Closed, если вам нужно добавить новый метод в иерархию или рефакторить сигнатуры методов до такой степени, что он ломает любой клиентский код. В конце концов, именно по этой причине в интерфейсы Java8 были добавлены методы по умолчанию, чтобы старый API можно было расширить, не требуя адаптации клиентского кода. Такой подход типичен для ООП.

Второй подход более характерен для ФП. В этом случае легко добавить методы, но сложно добавить новый тип (здесь нарушается O/C). Это хороший подход для закрытых иерархий, типичным примером являются алгебраические типы данных (ADT). Стандартизированный протокол, который не предназначен для расширения клиентами, может быть кандидатом.

Языки изо всех сил пытаются позволить разработать API, который имел бы оба преимущества - легко добавлять типы, а также добавлять методы. Эта проблема называется проблемой выражения. Scala предоставляет шаблон Typeclass для решения этой проблемы, который позволяет добавлять функциональные возможности к существующим типам ситуативным и выборочным образом.

Какой из них лучше, зависит от вашего варианта использования.