класс на языке ООП и тип

В теории языка программирования тип - это набор значений. Например, тип "int" - это набор всех целочисленных значений.

В языках ООП класс - это тип, не так ли?

Когда класс определен с более чем одним членом, например

class myclass{
    int a; 
    double b;
}

Когда мы говорим о классе, мы имеем в виду

• « (a,b)где aint и bдвойник», или
• "{ (x,y)| x- это любое int, yлюбое двойное}"?

Что означает экземпляр myclass?

• « (a,b)где aint и bдвойник», или
• объект, который занимает пространство памяти и который может (не обязательно, т. е. может быть пустым) хранить (x,y), где xнаходится какое-либо целое и yлюбое двойное число?

Ни.

Насколько я понимаю, вы спрашиваете, достаточно ли одного и того же набора типов полей для классификации как одного и того же класса, или же они должны называться одинаково. Ответ таков: «Даже одного и того же типа и одинаковых имен недостаточно!» Структурно эквивалентные классы не обязательно совместимы по типу.

Например, если у вас есть класс a CartesianCoordinatesи PolarCordinatesкласс, они могут иметь два числа в качестве своих полей, и они могут даже иметь один Numberи тот же тип и одинаковые имена, но они все равно не будут совместимы, и экземпляр класса PolarCoordinatesне будет экземпляр CartesianCoordinates. Возможность разделять типы по назначению, а не по их текущей реализации, является очень полезной частью написания более безопасного и более удобного в обслуживании кода.

Типы не являются наборами.

Видите ли, теория множеств имеет ряд особенностей, которые просто не применимы к типам, и наоборот . Например, объект имеет один канонический тип. Это может быть экземпляр нескольких разных типов, но только один из этих типов использовался для его создания. Теория множеств не имеет понятия «канонических» множеств.

Теория множеств позволяет вам создавать подмножества на лету , если у вас есть правило, которое описывает, что принадлежит подмножеству. Теория типов вообще не позволяет этого. В то время как большинство языков имеют Numberтип или что - то подобное, они не имеют EvenNumberтипа, и не было бы просто создать. Я имею в виду, достаточно просто определить сам тип, но любые существующие Numbers, которые оказываются даже, не будут волшебным образом преобразованы в EvenNumbers.

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

Наборы не могут прямо или косвенно содержать себя . Некоторые языки, такие как Python, предоставляют типы с менее регулярными структурами (в Python typeканонический тип есть typeи objectсчитается экземпляром object). С другой стороны, большинство языков не позволяют пользовательским типам участвовать в подобном обмане.

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

Пустой тип существует (он называется нижним типом ), но большинство языков его не поддерживают или не рассматривают как тип первого класса. «Тип, который содержит все другие типы», также существует (он называется верхним типом ) и широко поддерживается, в отличие от теории множеств.

NB . Как ранее указывали некоторые комментаторы (до того как поток был перемещен в чат), можно моделировать типы с помощью теории множеств и других стандартных математических конструкций. Например, вы можете моделировать членство в типе как отношение, а не моделировать типы как наборы. Но на практике это намного проще, если вы используете теорию категорий вместо теории множеств. Так Хаскелл моделирует свою теорию типов, например.

Понятие «подтип» действительно очень отличается от понятия «подмножество». Если Xэто подтип Y, это означает, что мы можем заменить экземпляры Yна экземпляры, Xи программа все равно будет «работать» в некотором смысле. Это скорее поведенческий, чем структурный характер, хотя некоторые языки (например, Go, Rust, возможно, C) выбрали последний из соображений удобства либо для программиста, либо для языковой реализации.

Алгебраические типы данных - способ обсудить это.

Существует три основных способа комбинирования типов:

• Товар. Это в основном то, о чем вы думаете:

  struct IntXDouble{
    int a; 
    double b;
  }
  

  тип продукта; его значения - все возможные комбинации (то есть кортежи) одного intи одного double. Если вы рассматриваете типы чисел как наборы, то количество элементов типа продукта фактически является результатом количества элементов поля.

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

  data IntOrDouble = AnInt Int
                   | ADouble Double
  

  значения этого типа имеют либо форму AnInt 345, либо ADouble 4.23, но всегда используется только одно число (в отличие от типа продукта, где каждое значение имеет два числа). Итак, кардинальность: сначала вы перечисляете все Intзначения, каждое из которых должно быть объединено с AnIntконструктором. Плюс ко всему, все Doubleзначения в сочетании с ADouble. Отсюда тип суммы .

• Возведение в степень ¹ . Я не буду обсуждать это подробно здесь, потому что оно не имеет четкой ОО-корреспонденции вообще.

Так что насчет классов? Я сознательно использовал ключевое слово, structа не classдля IntXDouble. Дело в том, что класс как тип на самом деле не характеризуется своими полями, это просто детали реализации. Ключевым фактором является то, какие различимые значения могут иметь класс.

Что это отношение , хотя это, значение того или иного класса может быть значения любого из его подклассов ! Таким образом, класс на самом деле является типом суммы, а не типом продукта: если Aи Bоба будут производными myClass, то myClass, по сути, будет суммой Aи B. Независимо от фактической реализации.

¹ _{Это функции (в математическом смысле! ); тип функции Int -> Doubleпредставлен экспоненциальным Double^Int. Плохо, если у вашего языка нет правильных функций ...}

Извините, но я не знаю о "сырой" теории. Я могу предоставить только практический подход. Я надеюсь, что это приемлемо для программистов. Я не знаком с этикетом здесь.

Центральная тема ООП - сокрытие информации . Что именно представляют собой члены класса, должны быть неинтересны для его клиентов. Клиент отправляет сообщения (вызывает методы / функции-члены) экземпляра, которые могут изменить или не изменить внутреннее состояние. Идея состоит в том, что внутренняя часть класса может измениться, без влияния на клиента.

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

    int areacode;
    int number;

Это данные членов класса. Тем не менее, класс, вероятно, будет намного больше, чем просто его члены данных, и он определенно не может быть определен как «набор всех возможных значений int x int». Вы не должны иметь прямого доступа к данным членов.

Построение экземпляра может отрицать любые отрицательные числа. Возможно, конструкция также каким-то образом нормализует ареакод или даже проверяет целое число. Таким образом , вы бы в конечном итоге гораздо ближе к вашему "(a,b) where a is an int and b is a double", потому что это , конечно , не какой - либо два ИНТ хранится в этом классе.

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

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

Существуют шаблоны проектирования, позволяющие гарантировать, что такие изменения внутреннего представления могут быть сделаны без ведома клиента (например, идиома pimpl в C ++, которая скрывает любые элементы данных за непрозрачным указателем ).

• Типа является описанием категории / диапазон значений, составных структур, или что у вас. OOPwise, это похоже на «интерфейс». (В не зависящем от языка смысле. Не так сильно intзависит от языка. В Java, например, это тип , но он не имеет отношения к interface. Спецификации открытых / защищенных полей также не являются частью interface, но являются частью "интерфейса" или типа .)

  Главное, что это гораздо больше семантическое определение, чем конкретное. Структурируйте только факторы, поскольку выявляемые поля / поведение и их определенные цели совпадают. Если у вас нет обоих, у вас нет совместимости типов.

• Класс является реализацией типа. Это шаблон, который на самом деле определяет внутреннюю структуру, прикрепленное поведение и т. Д.