У вас есть хорошая точка зрения по этому вопросу здесь:
Цель системы типов Scala
Беседа с Мартином Одерским, часть III
Билл Веннерс и Фрэнк Соммерс (18 мая 2009 г.)
Обновление (октябрь 2009 г.): то, что следует ниже, на самом деле проиллюстрировано в этой новой статье Биллом Веннерсом:
Элементы абстрактного типа и параметры общего типа в Scala (см. Резюме в конце)
(Вот соответствующая выдержка из первого интервью, май 2009 г., выделенное место)
Общий принцип
Всегда существовало два понятия абстракции:
- параметризация и
- абстрактные члены.
В Java у вас также есть оба, но это зависит от того, над чем вы абстрагируетесь.
В Java у вас есть абстрактные методы, но вы не можете передать метод в качестве параметра.
У вас нет абстрактных полей, но вы можете передать значение в качестве параметра.
И точно так же у вас нет членов абстрактного типа, но вы можете указать тип в качестве параметра.
Так что в Java у вас есть все три из них, но есть различие в том, какой принцип абстракции вы можете использовать для каких типов вещей. И вы можете утверждать, что это различие довольно произвольно.
Путь Скалы
Мы решили использовать одинаковые принципы построения для всех трех типов членов .
Таким образом, вы можете иметь как абстрактные поля, так и значения параметров.
Вы можете передавать методы (или «функции») в качестве параметров или абстрагироваться от них.
Вы можете указать типы в качестве параметров или абстрагироваться от них.
И что мы получаем концептуально, так это то, что мы можем моделировать одно с точки зрения другого. По крайней мере, в принципе, мы можем выразить любой вид параметризации как форму объектно-ориентированной абстракции. В некотором смысле вы можете сказать, что Scala - более ортогональный и законченный язык.
Почему?
То, что, в частности, абстрактные типы покупают вам, является хорошим решением для этих ковариационных проблем , о которых мы говорили ранее.
Одной из стандартных проблем, которая существует уже давно, является проблема животных и продуктов питания.
Головоломка состояла в том, чтобы иметь класс Animal с методом eat, который съедает немного еды.
Проблема в том, что если у нас есть подкласс Animal и у нас есть такой класс, как Cow, то они будут есть только траву, а не произвольную пищу. Например, корова не может есть рыбу.
То, что вы хотите, - это сказать, что у Коровы есть метод питания, который питается только травой, а не другими вещами.
На самом деле, вы не можете сделать это в Java, потому что оказывается, что вы можете создавать нездоровые ситуации, такие как проблема назначения Fruit переменной Apple, о которой я говорил ранее.
Ответ таков: вы добавляете абстрактный тип в класс Animal .
Вы говорите, мой новый класс животных имеет тип SuitableFood, которого я не знаю.
Так что это абстрактный тип. Вы не даете реализацию типа. Тогда у вас есть метод eat, который ест только SuitableFood.
А потом в классе Cow я бы сказал, ОК, у меня есть Корова, которая расширяет класс Animal, а для Cow type SuitableFood equals Grass.
Таким образом, абстрактные типы обеспечивают это представление о типе в суперклассе, который я не знаю, который я затем заполняю в подклассах чем-то, что я знаю .
То же самое с параметризацией?
Действительно, вы можете. Вы можете параметризовать класс Animal по типу пищи, которую он ест.
Но на практике , когда вы делаете это со многими разными вещами, это приводит к взрыву параметров , и обычно, что более того, в границах параметров .
На ECOOP 1998 года у Ким Брюса, Фила Уодлера и меня был документ, в котором мы показали, что по мере увеличения числа вещей, которые вы не знаете, типичная программа будет расти в квадрате .
Таким образом, есть очень веские причины не для того, чтобы задавать параметры, а для того, чтобы иметь эти абстрактные члены, потому что они не дают вам этого квадратичного разрыва.
thatismatt просит в комментариях:
Считаете ли вы, что это краткое изложение:
- Абстрактные типы используются в отношениях «имеет-а» или «использует-а» (например,
Cow eats Grass)
- где в качестве дженериков обычно используются отношения типа «из» (например,
List of Ints)
Я не уверен, что отношения отличаются между использованием абстрактных типов или обобщений.
Чем отличается:
- как они используются, и
- как управляются границы параметров.
Чтобы понять, о чем говорит Мартин, когда речь заходит о «взрыве параметров и, как правило, более того, в границах параметров » и его последующем квадратичном росте, когда абстрактный тип моделируется с использованием обобщений, Вы можете рассмотреть статью « Абстракция масштабируемых компонентов », написанную ... Мартином Одерским и Матиасом Ценгером для OOPSLA 2005, упоминаемую в публикациях проекта Palcom (закончено в 2007 г.).
Соответствующие выдержки
Определение
Элементы абстрактного типа предоставляют гибкий способ абстрагирования по конкретным типам компонентов.
Абстрактные типы могут скрывать информацию о внутренних компонентах компонента, аналогично их использованию в SML сигнатурах. В объектно-ориентированной среде, где классы могут быть расширены путем наследования, они также могут использоваться в качестве гибкого средства параметризации (часто называемого семейным полиморфизмом, см. Эту запись в блоге, например, , и статью, написанную Эрик Эрнст ).
(Примечание. Семейный полиморфизм был предложен для объектно-ориентированных языков в качестве решения для поддержки многоразовых, но безопасных для типов взаимно рекурсивных классов.
Ключевой идеей семейного полиморфизма является понятие семейств, которые используются для группировки взаимно рекурсивных классов)
абстракция ограниченного типа
abstract class MaxCell extends AbsCell {
type T <: Ordered { type O = T }
def setMax(x: T) = if (get < x) set(x)
}
Здесь объявление типа для T ограничено верхней границей типа , состоящей из упорядоченного имени класса и уточнения { type O = T }.
Верхняя граница ограничивает специализации T в подклассах теми подтипами Ordered, для которых член типа O из equals T.
Из-за этого ограничения метод < класса Ordered гарантированно применим к получателю и аргументу типа T.
Пример показывает, что член ограниченного типа может сам по себе отображаться как часть границы.
(т.е. Scala поддерживает F-ограниченный полиморфизм )
(Примечание, от Питера Кэннинга, Уильяма Кука, Уолтера Хилла, Уолтера Олтоффа:
Ограниченная квантификация была введена Карделли и Вегнером как средство типизации функций, которые работают равномерно по всем подтипам данного типа.
Они определили простую модель «объекта» и использовали ограниченную квантификацию для проверки функций, которые имеют смысл для всех объектов, имеющих указанный набор «атрибутов».
Более реалистичное представление объектно-ориентированных языков позволило бы объектам, являющимся элементами рекурсивно определенных типов .
В этом контексте ограниченное количественное определение больше не служит его назначению. Легко найти функции, которые имеют смысл для всех объектов, имеющих заданный набор методов, но которые нельзя набрать в системе Карделли-Вегнера.
Чтобы обеспечить основу для типизированных полиморфных функций в объектно-ориентированных языках, мы вводим F-ограниченную квантификацию)
Два лица одинаковых монет
В языках программирования существует две основные формы абстракции:
- параметризация и
- абстрактные члены.
Первая форма типична для функциональных языков, тогда как вторая форма обычно используется в объектно-ориентированных языках.
Традиционно Java поддерживает параметризацию для значений и абстракцию членов для операций.
Более поздняя версия Java 5.0 с обобщениями поддерживает параметризацию также для типов.
Аргументы для включения дженериков в Scala являются двоякими:
Во-первых, кодирование в абстрактные типы не так просто сделать вручную. Помимо потери краткости, существует также проблема случайного имени
конфликты между абстрактными именами типов, которые эмулируют параметры типов.
Во-вторых, обобщенные и абстрактные типы обычно выполняют разные роли в программах Scala.
- Обобщения обычно используются, когда требуется всего лишь экземпляр типа , тогда как
- абстрактные типы обычно используются, когда нужно обратиться к абстрактному
введите из кода клиента .
Последнее возникает, в частности, в двух ситуациях:
- Можно хотеть скрыть точное определение члена типа от клиентского кода, чтобы получить вид инкапсуляции, известный из модульных систем в стиле SML.
- Или можно переопределить тип ковариантно в подклассах, чтобы получить семейный полиморфизм.
В системе с ограниченным полиморфизмом переписывание абстрактного типа в дженерики может повлечь квадратичное расширение границ типа .
Обновление за октябрь 2009
Элементы абстрактного типа и параметры общего типа в Scala (Билл Веннерс)
(акцент мой)
Мое замечание по поводу абстрактных членов типа состоит в том, что они в первую очередь являются лучшим выбором, чем параметры универсального типа, когда:
- вы хотите, чтобы люди смешивали определения этих типов через черты .
- вы думаете, что явное упоминание имени члена типа при его определении поможет читабельности кода .
* +1246 * Пример: * * тысяча двести сорок семь
если вы хотите передать три различных объекта осветителей в тесты, вы сможете это сделать, но вам нужно будет указать три типа, по одному для каждого параметра. Таким образом, если бы я принял подход с параметром типа, ваши классы комплекта могли бы выглядеть так:
// Type parameter version
class MySuite extends FixtureSuite3[StringBuilder, ListBuffer, Stack] with MyHandyFixture {
// ...
}
Принимая во внимание, что при использовании члена типа это будет выглядеть так:
// Type member version
class MySuite extends FixtureSuite3 with MyHandyFixture {
// ...
}
Еще одно незначительное различие между членами абстрактного типа и параметрами универсального типа заключается в том, что при указании параметра универсального типа читатели кода не видят имя параметра типа. Таким образом, кто-то увидел эту строку кода:
// Type parameter version
class MySuite extends FixtureSuite[StringBuilder] with StringBuilderFixture {
// ...
}
Они не знали бы, каково было имя параметра типа, указанного как StringBuilder, без его поиска. Принимая во внимание, что имя параметра типа прямо в коде в подходе к абстрактному члену типа:
// Type member version
class MySuite extends FixtureSuite with StringBuilderFixture {
type FixtureParam = StringBuilder
// ...
}
В последнем случае читатели кода могут увидеть, что StringBuilder является типом «параметра прибора».
Им все еще нужно будет выяснить, что означает «параметр fixture», но они могут, по крайней мере, получить имя типа, не заглядывая в документацию.