Преимущества подтипов над классами типов

Question

Каковы преимущества OOP подтипов по сравнению с классами типов, если таковые имеются? Другими словами, теперь, когда у нас есть классы типов, есть ли причина по-прежнему использовать подтип OOP ?

PS: я программист Scala.

Answer 1

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

class MyEvent extends Event{
  val name = "foo"
}

, чем

class MyEvent{
   val name = "foo"
}

object MyEvent2Event{
   implicit def convert(myEvent:MyEvent) = new Event{ val name = myEvent.name}
}

Вторая форма дает гораздо большую гибкость с точки зрения пост-специального полиморфизма, свободы именования и общей плохой сборки, нонабрав эти пятьдесят методов преобразования, а затем выполнив соответствующие операции импорта, когда потребуется класс типов, станет настоящей болью.Если вам не нужна гибкость, сложно увидеть результат.Плюс ко всему, ворчливое «новое» ключевое слово во втором, которое будет порождать бесконечность, - это слишком сильные аргументы сборщика мусора.

Ситуация хуже для наследования mixin, которое вводит изменяемое состояние.Рассмотрим следующую черту, взятую из производственного кода:

trait Locking{
   private val lock = new ReentrantReadWriteLock()

   def withReadLock[T](body: => T):T={
      try{
         lock.readLock.lock()
         body
      }finally{
         lock.readLock.unlock()
      }
   }
   // same for withWriteLock
}

Невероятно удобное использование наследования mixin, и его невозможно реализовать с классами типов Scala из-за присутствия "lock" val.Куда это должно идти?Если вы поместите его в адаптированный класс, вы потеряете большую часть значения свойства.Если вы поместите его в код адаптера, блокировки больше не будут защищать, так как вы будете блокировать разные объекты блокировки каждый раз, когда вы будете адаптированы.

Answer 2

Лично я считаю, что с ООП легче справляться в рамках ограничений того, с чем он хорошо справляется. Другими словами: в случаях, когда вам на самом деле не нужно классов типов, я нахожу объекты более понятными.

Однако, это может быть просто артефакт синтаксических издержек, которые имеет типичное встраивание объектов класса типов. Если бы у Haskell был синтаксический сахар для некоторых распространенных типов шаблонов типов, это различие, вероятно, исчезло бы.

Что мне кажется более интересным, так это то, что сообщество Haskell показывает, что классы типов являются более мощными, чем объекты, поскольку существует тривиальное встраивание объектов в классы типов, но классы типов могут делать то, чего не могут делать объекты. Сообщество Scala, однако, показывает, что объекты по крайней мере столь же мощны, как классы типов ¹ , поскольку существует тривиальное вложение классов типов в объекты.

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

---

¹ См. Типовые классы как объекты и следствия , автор Bruno C.d.S. Оливейра, Адриан Мурс и Мартин Одерский, а также обсуждение этой статьи по Лямбда-ультиматум , особенно это прекрасное резюме Пола Снайвели (выделение добавлено):

Мартин Одерски и дизайнерские решения команды о том, как проводить уроки типов на унифицированном языке OO и FP, продолжают приносить плоды. Последствия все меньше и меньше напоминают «классы типов бедняков», и все больше и больше напоминают улучшение классов типов , на мой взгляд, с учетом краткого прочтения этой статьи.

Answer 3

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

Кроме того, подтипирование может быть более эффективным - это способ кэширования информации о том, что «X - это Y», не требуя повторного преобразования (или героики компилятора для кэширования этой информации) из X в Y. Для очень глубоких иерархий это может быть проблема.

Answer 4

Еще одно отличие для Scala, по крайней мере, состоит в том, что цепочки подтипов просто работают, тогда как цепочки классов типов намного сложнее.Если у нас есть типы A, B и C, то если A

Answer 5

Это может помочь:

http://www.haskell.org/haskellwiki/OOP_vs_type_classes

Answer 6

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

Некоторое время механизм разрешения экземпляров для классов типов убедил нас в том, что классы типов фундаментальнонедостатки из-за отсутствия безопасности ссылки.В отсутствие механизма разрешения с лексической областью разрешение экземпляра класса типов не может масштабироваться в человеческом смысле: изменение одной группы разработки может привести к ошибкам связывания в приложении, написанном в другом месте совершенно другой группой.Это заставило нас неохотно смотреть на единичное наследование и некоторую форму схемы F _< + SelfType.Существуют связанные проблемы, когда экземпляры имеют несколько разрешений с разной степенью специализации.</sub>

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

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

Джонатан Шапиро