Захищена скриня зі скарбами

Непрозорі типи

Вступ

Непрозорі типи - це техніка інкапсуляції в Elm. Дехто також називає це приховуванням інформації або приховуванням деталей реалізації. Їх також часто використовують, щоб забезпечити валідацію, застосовуючи підхід Розбирати, а не перевіряти. Наприклад, ми могли б мати непрозорий тип EmailAddress, який може містити лише дійсні адреси електронної пошти (на противагу String, який може містити будь-що).

Створення непрозорого типу

Власні типи мають один або кілька варіантів, і компілятор автоматично генерує функцію для створення кожного варіанта, використовуючи назву варіанта. Лише так можна створити власний тип. Компілятор також дозволяє деструктуризацію цих варіантів.

type Maybe a
    = Nothing --> Variant implies a 'Nothing' function, with type 'Maybe a', and destructuring of 'Nothing'
    | Just a  --> Variant implies a 'Just' function, with type 'a -> Maybe a', and destructuring of 'Just _'

Типово все це є внутрішнім для файлу / модуля, і ми використовуємо ключове слово exposing, щоб вибрати, що експортувати. Щоб створити непрозорий тип, ми просто вирішуємо не експортувати варіанти.

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

Розбирати, а не перевіряти

Мабуть, найпоширеніше застосування непрозорих типів - забезпечувати валідацію за допомогою підходу Розбирати, а не перевіряти. У цьому підході ми експортуємо функцію, яка приймає вхідні дані з меншою структурою / типовою безпекою, ніж нам потрібно, наприклад String, а потім розбирає їх у структурованіший тип, наприклад EmailAddress, і повертає або цей тип, або помилку (зазвичай Maybe чи Result).

Наприклад, у коді нижче зовнішні модулі можуть створити тип EmailAddress лише за допомогою функції parseEmailAddress, тож коли ми працюємо з типом EmailAddress, ми певні, що він дійсний.

module EmailAddress exposing ( EmailAddress, parseEmailAddress, getEmailAddress )

-- The `EmailAddress` custom type has one variant, also called `EmailAddress`
-- When a custom type has one variant, it is idiomatic to use the same name for both.
type EmailAddress = 
  EmailAddress String

-- create an EmailAddress variant
parseEmailAddress: String -> Maybe EmailAddress
parseEmailAddress candidateEmailAddress =   
  if isValidEmailAddress candidateEmailAddress then
    Just (EmailAddress candidateEmailAddress)
  else
    Nothing

-- get an EmailAddress variant
getEmailAddress: EmailAddress -> String
getEmailAddress ( EmailAddress  emailAdress ) =
  emailAdress

isValidEmailAddress: String -> bool
-- ...