Скала и интерфейсы

Question

В Java я обычно объявляю весь свой домен как interface s, возможно, с каким-то Factory, чтобы получить свои реализации. Это отчасти потому, что я настолько стар, что я могу вспомнить, когда некоторым уровням персистентности требовались классы реализации для создания подкласса определенного класса, но я мог легко:

• макет объектов для тестирования
• прокси-объекты во время выполнения при необходимости
• предоставляет различные реализации

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

Будет ли это необычным для Scala-land, если я объявлю все доменные объекты abstract? Приведенные выше пункты верны и для Скалы?

Answer 1

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

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

Добавьте к этому компаньону объекты, и внезапно фабрики и многое другое станут гораздо более тривиальными.

Учитывая это, вы действительно можете избавиться от необходимости использовать интерфейсы повсюду, и с более мощной системой универсальных обобщений, часть того, что делается с помощью интерфейсов, поглощается там.

В целом, при взгляде на код Scala, он имеет тенденцию быть довольно разложенным, и интерфейсы, кажется, не являются основным инструментом в этом.

Answer 2

Это действительно наводящий на размышления вопрос.

Кажется, это не обычная модель (по крайней мере, в Scala, которую я видел), но я не могу придумать хороший аргумент против этого, если вы действительно этого хотите. делать.

С другой стороны, я не думаю, что я бы сделал бы это таким образом (я бы осуществил рефакторинг, когда у меня была реальная потребность, вместо того, чтобы строить такую ​​"гибкость" для гипотетического будущего что может никогда не прийти). Но лучший аргумент против этого, который я могу придумать, - это аналогия избегания ненужной косвенности (не используйте указатель на указатель на указатель на целое число, когда все, что вам нужно, это целое число), и это не очень убедительно.