клас з мови та типу OOP

У теорії мови програмування тип - це набір значень. Наприклад, тип "int" - це набір усіх цілих значень.

У мовах OOP клас - це тип, чи не так?

Коли клас визначено з більш ніж одним членом, наприклад

class myclass{
    int a; 
    double b;
}

Коли ми говоримо про клас, маємо на увазі

• " (a,b)де aє int і bє подвійним", або
• "{ (x,y)| xбудь-який int, чи yє подвійний}"?

Що означає екземпляр myclass?

• " (a,b)де aє int і bє подвійним", або
• об’єкт, який займає простір пам'яті і який може (не обов'язково, тобто може бути порожнім) зберігати (x,y), де xє будь-який int і чи yє якийсь подвійний?

Ні.

Я вважаю, що ви запитуєте, чи достатньо мати один і той же набір типів полів, щоб класифікувати їх як один клас, чи повинні вони також бути названі однаково. Відповідь така: "Досить навіть мати однакові типи та однакові імена!" Структурно еквівалентні класи не обов'язково сумісні з типом.

Наприклад, якщо у вас є клас CartesianCoordinatesі PolarCordinatesклас, вони можуть мати два числа як свої поля, і вони можуть мати навіть один і той же Numberтип і однакові імена, але вони все одно не будуть сумісні, і екземпляр PolarCoordinatesне буде екземпляр CartesianCoordinates. Здатність окремих видів за їх прямим призначенням , а не їх поточної реалізація є дуже корисною частиною написання більш безпечним, більш супроводу коду.

Типи не є наборами.

Розумієте, теорія множин має ряд особливостей, які просто не стосуються типів, і навпаки . Наприклад, об’єкт має єдиний канонічний тип. Це може бути екземпляр декількох різних типів, але лише один з цих типів був використаний для інстанції. Теорія множин не має поняття "канонічних" множин.

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

Насправді, сказати, що ви можете "створити" підмножини, є дещо хитруватим, оскільки набори - це зовсім інший вид тварин. У теорії множин ці підмножини вже існують усіма нескінченними способами їх визначення. У теорії типів ми зазвичай розраховуємо мати справу з кінцевою (якщо великою) кількістю типів у будь-який момент часу. Єдині типи, про які кажуть, є ті, які ми насправді визначили, а не кожен тип, який ми могли б визначити.

Наборам заборонено прямо або опосередковано стримуватися . Деякі мови, такі як Python, надають типи з менш регулярними структурами (у Python, typeканонічний тип є type, і objectвважається екземпляром object). З іншого боку, більшість мов не дозволяють визначеним користувачем типам займатися подібними хитрощами.

Набори, як правило, дозволяють перекриватися, не містячись один в одному. Ця теорія є рідкістю, хоча деякі мови підтримують її у вигляді багаторазового успадкування. Інші мови, як-от Java, дозволяють лише обмежену форму цього або забороняють його повністю.

Порожній тип існує (він називається нижній тип ), але більшість мов не підтримує його чи не розглядає як тип першого класу. Також існує "тип, який містить усі інші типи" (він називається верхній тип ) і широко підтримується, на відміну від теорії множин.

NB : Як раніше зазначали деякі коментатори (до того, як нитка була перенесена в чат), можна моделювати типи з теорією множин та іншими стандартними математичними конструкціями. Наприклад, ви можете моделювати членство як відношення, а не моделювання типів як наборів. Але на практиці це набагато простіше, якщо використовувати теорію категорій замість теорії множин. Так, наприклад, Haskell моделює свою теорію типів.

Поняття «підтипу» насправді зовсім відрізняється від поняття «підмножина». Якщо 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. До поганого, якщо ваша мова не має належних функцій ...}

Вибачте, але я не знаю про "сиру" теорію. Я можу запропонувати лише практичний підхід. Я сподіваюся, що це прийнятно у програмістів.SE; Я тут не знайомий з етикетом.

Центральною темою ООП є приховування інформації . Які саме дані є членами класу, не повинні цікавити його клієнтів. Клієнт відправляє повідомлення (методи виклику / функції члена) екземпляра, який може або не може змінити внутрішній стан. Ідея полягає в тому, що внутрішні класи класу можуть змінюватися, не впливаючи на нього клієнта.

Підтвердженням цього є те, що клас відповідає за те, щоб його внутрішнє представлення залишалося "дійсним". Припустимо клас, який зберігає (спрощений) номер телефону у два цілі числа:

    int areacode;
    int number;

Це члени даних класу. Однак клас, ймовірно, буде набагато більше, ніж просто його члени даних, і його, звичайно, не можна визначити як "набір усіх можливих значень int x int". Ви не повинні мати прямий доступ до учасників даних.

Побудова екземпляра може заперечувати будь-які негативні числа. Можливо, конструкція також якось нормалізувала б код коду або навіть перевірила б ціле число. Таким чином , ви б в кінцевому підсумку набагато ближче до вашого "(a,b) where a is an int and b is a double", тому що це , звичайно , НЕ який - або два ІНТ зберігається в цьому класі.

Але це не дуже важливо, що стосується класу. Клас не визначає ані тип членів даних, ані діапазон їх можливих значень. Це методи , визначені для нього.

Поки ці методи залишаються однаковими, реалізатор може змінювати типи даних на плаваючу крапку, BIGNUM, рядки, будь-які, і для всіх практичних цілей це буде все той же клас .

Існують дизайнерські малюнки, які гарантують, що такі зміни внутрішнього представництва можуть бути здійснені, навіть якщо клієнт цього не усвідомлює (наприклад, ідіома pimpl в C ++, яка ховає будь-яких членів даних за непрозорим покажчиком ).

• Типу є описом категорії / діапазон значень, складових структур, або що у вас. OOPwise, це схоже на "інтерфейс". (У мовно-агностичному сенсі. Мовно-специфічний сенс не так вже й багато. Наприклад, у Java intце тип , але не має відношення до interface. Загальнодоступні / захищені специфікації поля також не є частиною interface, але є частиною "інтерфейсу" або типу .)

  Головне, це набагато більше семантичне визначення, ніж конкретне. Структуруйте лише фактори, наскільки вирівнюються відкриті поля / поведінки та їх визначені цілі . Якщо у вас немає обох, у вас немає сумісності типів.

• Клас є реалізацією типу. Це шаблон, який фактично визначає внутрішню структуру, прикріплену поведінку тощо.