Можно ли реализовать инкапсуляцию средствами ООП?

Конкуретность сама по себе противоречит инкапсуляции

Инкапсуляция не скрывает наличие и влияние состояния. Она запрещает небезопасный способ работы с ним.

блокировать монетоприёмник и считыватель карт пока турникет открыт - это штатное поведение и инкапсуляции не противоречит

Я вот все еще не понял, почему выброс исключения это кишки наружу? потому что вы изначально о требовании "температура не более 273.15" не написали? ну какбы проблема тогда ищется не там.

Не нравится вам исключение - напишите обертку над double, которая будет представлять собой число double гарантированно укладывающееся в требуемый диапазон, и принимайте в сеттере ее.

Вам в любом случае нужно предоставлять какие-то рамки использования для потребителей вашей библиотеки - если любые рамки это "кишки наружу" то кажется вы ситх.

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

Ну то такое...

Появляется новый тип ошибки: "уже активирован другой проход". Если вы готовы его обработать новым способом, то вводите. Если не готовы, то это будет просто "неопознанная ошибка"

Следовало и ждать такого заявления, как в этой статье.
Инкапсуляция очень условное понятие. Принцип кота Шредингера как раз демонстрирует ее, причем не как достижение а как суть проблемы. Или же в более простом варианте как-то ходил снимок какого-то устройства открыв которое стало видно что попросту замкнуты между столбовой 2 разъема и вложена бумажка с ответом вопросом на логично возникающий вопрос.
Тем не мнение и эта абстракция позволяла нам как раз абстрагироваться от сложностей но не гарантировала возможности спрятаться от них. Абстрагируясь от сложностей мы концентрируемся на том что делаем. Например зачем нам знать в каком состоянии находится контролер I²C порта, в моменты когда остальная задача никак не зависит от его текущего состояния, как собственно и на оборот.
Тем не мнение если I²C и остальная задача зависят друг от друга, то им придется взаимодействовать.
Эта статья появилась тогда после активного использования нейронных сетей, программисты вдруг заметили что нейронным сетям плохо даются некоторые вещи как-то объектно-ориентированный анализ.
Объектно-ориентированное программирование не обязательно C++. На чистом C модно получить те же самые абстракции, правда методы придется выделять конвенциально (просто помнить что такие-то функции к относятся к такому-то объекту) а инкапсулированние данные указывать в параметре каждой функции. Правда опять же конвенциально придется не делать с ними то что нельзя. В принципе то же самое делает надстройка над компилятором C для языка ObjectiveC.
Но можно попробовать пойти дальше в языки программирования сверхвысокого уровня, например CIAO этот язык хоть и позволяет много достичь но еще и более требователен в частности к Объектно Ориентированному Анализу, и вероятно поэтому, мало распространен.

Непонятно, как без обработки ошибок реализовать инициализацию типа Temperature из пользовательских данных в не-ООП языках?
Ну вот читаем показания датчика через порт и оттуда внезапно прилетели условные -300 градусов. И что с этим будем делать, в рамках некой идеальной инкапсуляции в не-ООП языках?

нам надо бы обработать случай value < 273.15

Тут сразу несколько проблем.

1. Требования не проанализированы. По всей видимости быстро написали реализацию и в продакшен.

2. Дизайн не продуман. А надо было бы его нарисовать, выделить интерфейс для работы с температурой, продумать граничные условия, механизм передачи ошибок и т. д. И т. П. .

3. Если уж требования поменялись, то делайте новую реализацию. Но так как у вас тут все будет зависеть от конкретного класса, а не от интерфейса. То все считайте приехали. Был бы интерфейс можно было бы новую реализацию сделать с проверками, а так все менять придётся.

4. Если уж вообще требования поменялись, то и вводите новый интерфейс и расширяйте реализацию.

В общем, моё мнение проблема тут в подходе к разработке, сразу код и в продакшен. Так не надо, надо хоть маломальский анализ и Дизайн прикинуть. Иначе код превратиться в лапшу при любой парадигме программирования.

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

Компромиссом являются: unsafe в расте, Any в тайпскрипте, и  

Ну причем тут ООП?

Вот вполне нормальные реализации на ООП

import threading
import time
from enum import Enum, auto

# --- Вспомогательные компоненты (Заглушки) ---

class Mechanism:
    def lock(self): print("DEBUG: Mechanism LOCKED")
    def unlock(self): print("DEBUG: Mechanism UNLOCKED")

class Timer:
    def __init__(self, timeout_seconds, callback):
        self._timeout = timeout_seconds
        self._callback = callback
        self._timer_thread = None
        self._lock = threading.Lock()

    def start(self):
        with self._lock:
            self.cancel() # Отменяем предыдущий, если был
            print(f"DEBUG: Timer STARTED ({self._timeout}s)")
            self._timer_thread = threading.Timer(self._timeout, self._handle_timeout)
            self._timer_thread.start()

    def cancel(self):
        with self._lock:
            if self._timer_thread and self._timer_thread.is_alive():
                print("DEBUG: Timer CANCELLED")
                self._timer_thread.cancel()
            self._timer_thread = None

    def _handle_timeout(self):
        print("DEBUG: Timer FIRED (Timeout)")
        self._callback() # Вызываем обработчик таймаута в турникете

class Indicator:
    def turn_green(self): print("DEBUG: Indicator GREEN")
    def turn_red(self): print("DEBUG: Indicator RED")

class PaymentSystem:
    def accept_coin(self): print("DEBUG: Coin ACCEPTED")
    def accept_ticket(self): print("DEBUG: Ticket ACCEPTED")
    def return_coin(self): print("DEBUG: Coin RETURNED")
    # В реальной системе тут была бы валидация, списание и т.д.

# --- Основной класс Турникета ---

class TurnstileState(Enum):
    LOCKED = auto()
    UNLOCKED = auto()

class TurnstileEventResult(Enum):
    SUCCESS = auto()
    ERROR_ALREADY_UNLOCKED = auto()
    ERROR_ALREADY_LOCKED = auto() # Например, при попытке пройти через запертый
    ERROR_INVALID_PAYMENT = auto() # Если бы была валидация
    ERROR_TIMEOUT = auto() # Сигнал от таймаута

class Turnstile:
    def __init__(self, mechanism: Mechanism, timer: Timer, indicator: Indicator, payment_system: PaymentSystem, timeout_duration=5):
        self._state = TurnstileState.LOCKED
        self._mechanism = mechanism
        self._timer = Timer(timeout_duration, self._handle_timeout) # Таймер вызывает наш внутренний метод
        self._indicator = indicator
        self._payment_system = payment_system
        self._lock = threading.Lock() # Для потокобезопасности

        # Начальная настройка
        self._mechanism.lock()
        self._indicator.turn_red()

    def get_state(self):
        with self._lock:
            return self._state

    def insert_coin(self) -> TurnstileEventResult:
        with self._lock:
            print(f"\nEVENT: COIN received (Current State: {self._state.name})")
            if self._state == TurnstileState.UNLOCKED:
                print("ACTION: Coin rejected (already unlocked)")
                self._payment_system.return_coin()
                return TurnstileEventResult.ERROR_ALREADY_UNLOCKED

            # Переход LOCKED -> UNLOCKED
            self._state = TurnstileState.UNLOCKED
            self._payment_system.accept_coin()
            self._mechanism.unlock()
            self._indicator.turn_green()
            self._timer.start()
            print(f"STATE CHANGE: -> {self._state.name}")
            return TurnstileEventResult.SUCCESS

    def insert_ticket(self) -> TurnstileEventResult:
        with self._lock:
            print(f"\nEVENT: TICKET received (Current State: {self._state.name})")
            if self._state == TurnstileState.UNLOCKED:
                print("ACTION: Ticket rejected (already unlocked)")
                # Обычно билет просто не принимается повторно
                return TurnstileEventResult.ERROR_ALREADY_UNLOCKED

            # Переход LOCKED -> UNLOCKED
            self._state = TurnstileState.UNLOCKED
            self._payment_system.accept_ticket() # Предполагаем успешную валидацию/списание
            self._mechanism.unlock()
            self._indicator.turn_green()
            self._timer.start()
            print(f"STATE CHANGE: -> {self._state.name}")
            return TurnstileEventResult.SUCCESS

    def pass_through(self) -> TurnstileEventResult:
         with self._lock:
            print(f"\nEVENT: PASS detected (Current State: {self._state.name})")
            if self._state == TurnstileState.LOCKED:
                print("ACTION: Pass attempt blocked (Alarm?)")
                # Можно добавить логику тревоги
                return TurnstileEventResult.ERROR_ALREADY_LOCKED

            # Переход UNLOCKED -> LOCKED
            self._state = TurnstileState.LOCKED
            self._timer.cancel()
            self._mechanism.lock()
            self._indicator.turn_red()
            print(f"STATE CHANGE: -> {self._state.name}")
            return TurnstileEventResult.SUCCESS

    def _handle_timeout(self):
        # Этот метод вызывается из потока таймера, поэтому нужна блокировка
        with self._lock:
            print(f"\nEVENT: TIMEOUT detected (Current State: {self._state.name})")
            # Таймаут имеет смысл только если мы все еще UNLOCKED
            if self._state == TurnstileState.UNLOCKED:
                # Переход UNLOCKED -> LOCKED по таймауту
                self._state = TurnstileState.LOCKED
                self._mechanism.lock()
                self._indicator.turn_red()
                print(f"STATE CHANGE: -> {self._state.name} (due to timeout)")
                # Можно сигнализировать об этом событии вовне, если нужно
                # return TurnstileEventResult.ERROR_TIMEOUT # Возвращать некому, т.к. вызвано таймером
            else:
                # Таймаут пришел, когда уже LOCKED (например, успели пройти) - игнорируем
                print("ACTION: Timeout ignored (already locked)")

# --- Пример использования ООП ---
print("--- OOP Turnstile Demo ---")
mech = Mechanism()
indi = Indicator()
pay_sys = PaymentSystem()
# Timer будет создан внутри Turnstile

turnstile_oop = Turnstile(mech, None, indi, pay_sys, timeout_duration=3) # Timer создается внутри

print(f"Initial State: {turnstile_oop.get_state().name}")

result = turnstile_oop.insert_coin()
print(f"Coin Insert Result: {result.name}")
print(f"State after Coin: {turnstile_oop.get_state().name}")

time.sleep(1) # Даем время пройти

result = turnstile_oop.pass_through()
print(f"Pass Result: {result.name}")
print(f"State after Pass: {turnstile_oop.get_state().name}")

print("-" * 20)

result = turnstile_oop.insert_ticket()
print(f"Ticket Insert Result: {result.name}")
print(f"State after Ticket: {turnstile_oop.get_state().name}")

# Пытаемся вставить монету, пока открыто
result = turnstile_oop.insert_coin()
print(f"Second Coin Insert Result: {result.name}")
print(f"State after second Coin: {turnstile_oop.get_state().name}")

print("Waiting for timeout...")
time.sleep(4) # Ждем дольше таймаута
print(f"State after Timeout: {turnstile_oop.get_state().name}")
print("--- OOP Demo End ---")

И ФП:

import time
import threading
from typing import Tuple, List, Any, Dict

# --- Определения состояний, событий, действий (данные) ---
STATE_LOCKED = "LOCKED"
STATE_UNLOCKED = "UNLOCKED"

EVENT_COIN = "COIN"
EVENT_TICKET = "TICKET"
EVENT_PASS = "PASS"
EVENT_TIMEOUT = "TIMEOUT"
EVENT_INVALID = "INVALID" # Пример невалидного входа
EVENT_ATTEMPT_PASS = "ATTEMPT_PASS" # Попытка пройти без оплаты

# Действия - это команды для внешнего исполнителя
ACTION_LOCK_MECHANISM = "LOCK_MECHANISM"
ACTION_UNLOCK_MECHANISM = "UNLOCK_MECHANISM"
ACTION_START_TIMER = "START_TIMER"
ACTION_CANCEL_TIMER = "CANCEL_TIMER"
ACTION_GREEN_LIGHT = "GREEN_LIGHT"
ACTION_RED_LIGHT = "RED_LIGHT"
ACTION_ACCEPT_COIN = "ACCEPT_COIN"
ACTION_RETURN_COIN = "RETURN_COIN"
ACTION_ACCEPT_TICKET = "ACCEPT_TICKET"
ACTION_SIGNAL_ALARM = "SIGNAL_ALARM"

# Результаты для внешнего мира (могут быть частью действий)
SIGNAL_SUCCESS = ("SIGNAL", "SUCCESS")
SIGNAL_ERROR_ALREADY_UNLOCKED = ("SIGNAL", "ERROR_ALREADY_UNLOCKED")
SIGNAL_ERROR_ALREADY_LOCKED = ("SIGNAL", "ERROR_ALREADY_LOCKED")
SIGNAL_ERROR_TIMEOUT = ("SIGNAL", "ERROR_TIMEOUT")
SIGNAL_ERROR_INVALID_PAYMENT = ("SIGNAL", "ERROR_INVALID_PAYMENT")

# --- Чистая функция перехода состояний ---
def handle_event(current_state: str, event: str) -> Tuple[str, List[Any]]:
    """
    Чистая функция: принимает состояние и событие, возвращает новое состояние и список действий.
    Не выполняет никаких побочных эффектов сама.
    """
    if current_state == STATE_LOCKED:
        if event == EVENT_COIN:
            # Переход LOCKED -> UNLOCKED
            new_state = STATE_UNLOCKED
            actions = [ACTION_ACCEPT_COIN, ACTION_UNLOCK_MECHANISM, ACTION_GREEN_LIGHT, ACTION_START_TIMER, SIGNAL_SUCCESS]
            return new_state, actions
        elif event == EVENT_TICKET:
             # Переход LOCKED -> UNLOCKED
            new_state = STATE_UNLOCKED
            actions = [ACTION_ACCEPT_TICKET, ACTION_UNLOCK_MECHANISM, ACTION_GREEN_LIGHT, ACTION_START_TIMER, SIGNAL_SUCCESS]
            return new_state, actions
        elif event == EVENT_ATTEMPT_PASS:
            return STATE_LOCKED, [ACTION_SIGNAL_ALARM, SIGNAL_ERROR_ALREADY_LOCKED]
        elif event in [EVENT_PASS, EVENT_TIMEOUT]: # Нерелевантные события
             return STATE_LOCKED, []
        else: # Неизвестное или невалидное событие
             return STATE_LOCKED, [ACTION_RETURN_COIN, SIGNAL_ERROR_INVALID_PAYMENT] # Пример

    elif current_state == STATE_UNLOCKED:
        if event == EVENT_PASS:
            # Переход UNLOCKED -> LOCKED
            new_state = STATE_LOCKED
            actions = [ACTION_CANCEL_TIMER, ACTION_LOCK_MECHANISM, ACTION_RED_LIGHT, SIGNAL_SUCCESS]
            return new_state, actions
        elif event == EVENT_TIMEOUT:
             # Переход UNLOCKED -> LOCKED
            new_state = STATE_LOCKED
            actions = [ACTION_LOCK_MECHANISM, ACTION_RED_LIGHT, SIGNAL_ERROR_TIMEOUT] # Таймер сам себя не отменяет
            return new_state, actions
        elif event == EVENT_COIN:
            # Монета во время разблокировки
            return STATE_UNLOCKED, [ACTION_RETURN_COIN, SIGNAL_ERROR_ALREADY_UNLOCKED]
        elif event == EVENT_TICKET:
             # Билет во время разблокировки
            return STATE_UNLOCKED, [SIGNAL_ERROR_ALREADY_UNLOCKED] # Билет просто игнорируется
        elif event == EVENT_ATTEMPT_PASS: # Попытка пройти вторым - игнор или аларм? Пусть будет аларм.
            return STATE_UNLOCKED, [ACTION_SIGNAL_ALARM]
        else: # Неизвестное событие
            return STATE_UNLOCKED, []

    # На случай непредвиденного состояния
    return current_state, []

# --- Внешний "Рантайм" или "Исполнитель" ---
# (Упрощенная симуляция, в реальности это был бы цикл обработки событий)

class FunctionalTurnstileRuntime:
    def __init__(self, timeout_duration=5):
        self._current_state = STATE_LOCKED
        self._timeout_duration = timeout_duration
        self._timer_handle = None # Храним объект таймера (например, threading.Timer)
        self._lock = threading.Lock() # Для атомарности обработки событий

        # Заглушки для реальных действий
        self._mechanism_state = "LOCKED"
        self._indicator_state = "RED"
        print(f"FP Runtime Init: State={self._current_state}, Mech={self._mechanism_state}, Indic={self._indicator_state}")

    def _execute_actions(self, actions: List[Any]):
        """ Выполняет побочные эффекты, управляемые извне """
        print(f"  Executing Actions: {actions}")
        last_signal = None
        for action in actions:
            if isinstance(action, tuple) and action[0] == "SIGNAL":
                print(f"    SIGNAL: {action[1]}")
                last_signal = action[1] # Запоминаем последний сигнал для возврата
            elif action == ACTION_LOCK_MECHANISM:
                self._mechanism_state = "LOCKED"; print("    ACTION: Mechanism LOCKED")
            elif action == ACTION_UNLOCK_MECHANISM:
                 self._mechanism_state = "UNLOCKED"; print("    ACTION: Mechanism UNLOCKED")
            elif action == ACTION_START_TIMER:
                self._cancel_timer_internal() # Отменяем старый, если есть
                print(f"    ACTION: Timer STARTED ({self._timeout_duration}s)")
                self._timer_handle = threading.Timer(self._timeout_duration, lambda: self.process_event(EVENT_TIMEOUT))
                self._timer_handle.start()
            elif action == ACTION_CANCEL_TIMER:
                self._cancel_timer_internal()
            elif action == ACTION_GREEN_LIGHT:
                 self._indicator_state = "GREEN"; print("    ACTION: Indicator GREEN")
            elif action == ACTION_RED_LIGHT:
                 self._indicator_state = "RED"; print("    ACTION: Indicator RED")
            elif action == ACTION_ACCEPT_COIN: print("    ACTION: Coin ACCEPTED")
            elif action == ACTION_RETURN_COIN: print("    ACTION: Coin RETURNED")
            elif action == ACTION_ACCEPT_TICKET: print("    ACTION: Ticket ACCEPTED")
            elif action == ACTION_SIGNAL_ALARM: print("    ACTION: ALARM!")
            # ... другие действия ...
        return last_signal # Возвращаем последний сигнал как результат операции

    def _cancel_timer_internal(self):
         if self._timer_handle and self._timer_handle.is_alive():
             print("    ACTION: Timer CANCELLED")
             self._timer_handle.cancel()
         self._timer_handle = None

    def process_event(self, event: str) -> Any:
        """
        Главный метод обработки события:
        1. Блокировка для атомарности.
        2. Вызов чистой функции handle_event.
        3. Обновление внутреннего состояния.
        4. Разблокировка.
        5. Выполнение действий (побочных эффектов).
        """
        print(f"\nFP EVENT: {event} (Current State: {self._current_state})")
        with self._lock:
            new_state, actions = handle_event(self._current_state, event)
            if new_state != self._current_state:
                 print(f"  STATE CHANGE: {self._current_state} -> {new_state}")
                 self._current_state = new_state
            else:
                 print(f"  State unchanged: {self._current_state}")
            # Копируем actions, чтобы выполнить их вне блокировки (если нужно)
            actions_to_execute = list(actions)

        # Выполнение действий происходит после освобождения блокировки состояния
        # (Хотя запуск/остановка таймера тоже требуют синхронизации, как в _execute_actions)
        result_signal = self._execute_actions(actions_to_execute)
        return result_signal # Возвращаем сигнал от выполнения действий

    def get_current_state_info(self): # Для отладки
        return f"FP State={self._current_state}, Mech={self._mechanism_state}, Indic={self._indicator_state}"

# --- Пример использования ФП ---
print("\n--- FP Turnstile Demo ---")
turnstile_fp = FunctionalTurnstileRuntime(timeout_duration=3)

print(f"Initial: {turnstile_fp.get_current_state_info()}")

result = turnstile_fp.process_event(EVENT_COIN)
print(f"Coin Insert Result Signal: {result}")
print(f"State after Coin: {turnstile_fp.get_current_state_info()}")

time.sleep(1)

result = turnstile_fp.process_event(EVENT_PASS)
print(f"Pass Result Signal: {result}")
print(f"State after Pass: {turnstile_fp.get_current_state_info()}")

print("-" * 20)

result = turnstile_fp.process_event(EVENT_TICKET)
print(f"Ticket Insert Result Signal: {result}")
print(f"State after Ticket: {turnstile_fp.get_current_state_info()}")

# Пытаемся вставить монету, пока открыто
result = turnstile_fp.process_event(EVENT_COIN)
print(f"Second Coin Insert Result Signal: {result}")
print(f"State after second Coin: {turnstile_fp.get_current_state_info()}")

print("Waiting for timeout...")
time.sleep(4) # Ждем обработку TIMEOUT внутри runtime
print(f"State after Timeout: {turnstile_fp.get_current_state_info()}")
print("--- FP Demo End ---")

Или даже имитация зависимых состояний

// 1. Типы-маркеры для состояний
struct Locked;
struct Unlocked;

// 2. Основная структура, параметризованная состоянием
struct Turnstile<State> {
    // Общие данные турникета, если есть
    id: String,
    // Важно: State - это тип-маркер, он не занимает места в памяти
    _state: std::marker::PhantomData<State>,
}

// 3. Реализация методов для СОСТОЯНИЯ LOCKED
impl Turnstile<Locked> {
    pub fn new(id: String) -> Self {
        println!("{} is LOCKED", id);
        // ... инициализация механизма ...
        Turnstile { id, _state: std::marker::PhantomData }
    }

    // Этот метод доступен ТОЛЬКО для Turnstile<Locked>
    // Он "потребляет" self и возвращает новый турникет в состоянии Unlocked
    pub fn insert_coin(self) -> Turnstile<Unlocked> {
        println!("{} Coin accepted, UNLOCKING", self.id);
        // ... разблокировать механизм, запустить таймер ...
        Turnstile { id: self.id, _state: std::marker::PhantomData }
    }

     pub fn insert_ticket(self) -> Turnstile<Unlocked> {
        println!("{} Ticket accepted, UNLOCKING", self.id);
        // ... разблокировать механизм, запустить таймер ...
        Turnstile { id: self.id, _state: std::marker::PhantomData }
    }

    // Попытка вызвать pass() на Turnstile<Locked> просто не скомпилируется!
    // pub fn pass(self) -> ??? { ... } // Ошибка! Нет такого метода для Locked.
}

// 4. Реализация методов для СОСТОЯНИЯ UNLOCKED
impl Turnstile<Unlocked> {
    // Этот метод доступен ТОЛЬКО для Turnstile<Unlocked>
    pub fn pass(self) -> Turnstile<Locked> {
        println!("{} Passed, LOCKING", self.id);
        // ... остановить таймер, заблокировать механизм ...
        Turnstile { id: self.id, _state: std::marker::PhantomData }
    }

     pub fn timeout(self) -> Turnstile<Locked> {
        println!("{} Timeout, LOCKING", self.id);
         // ... заблокировать механизм ...
        Turnstile { id: self.id, _state: std::marker::PhantomData }
    }

    // Попытка вызвать insert_coin() на Turnstile<Unlocked> не скомпилируется!
}

// --- Использование ---
fn main() {
    let t1 = Turnstile::<Locked>::new("T1".to_string());

    // Это компилируется: insert_coin() определен для Turnstile<Locked>
    let t2: Turnstile<Unlocked> = t1.insert_coin();

    // Это компилируется: pass() определен для Turnstile<Unlocked>
    let t3: Turnstile<Locked> = t2.pass();

    // А вот это НЕ СКОМПИЛИРУЕТСЯ:
    // let t4 = t3.pass();
    // error[E0599]: no method named `pass` found for struct `Turnstile<Locked>` in the current scope
    //   --> src/main.rs:67:16
    //    |
    // 67 |     let t4 = t3.pass();
    //    |                ^^^^ method not found in `Turnstile<Locked>`

    // И это НЕ СКОМПИЛИРУЕТСЯ:
    // let t2_again = Turnstile::<Unlocked>::new("T2".to_string()); // Нет такого конструктора
    // let t5 = t3.insert_coin();
    // error[E0599]: no method named `insert_coin` found for struct `Turnstile<Locked>`

    println!("Final state type check successful (compilation passed).");
}

encapsulation prevents external code from being concerned with the internal workings of an object
Инкапсуляция должна бы запретить любое изменение внутреннего состояния сущности (объекта) извне любым способом, кроме специально разрешенных автором.

Почему у вас "prevents external code from being concerned" вдруг превратилось в "forbids external code to be able to change"? "Сoncerned" и "change" это же не синонимы. Если вызывающий код не имеет доступа к private-полям, то он уже "prevented", потому что вы можете переименовать поля эти поля и поменять их типы, не меняя вызывающий код.

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

Если исключение или код возврата описаны в сигнатуре, то это ничем не отличается от типа возвращаемого значения, и является частью протокола взаимодействия, а не деталями реализации.

Что-то предпринять, определенно, надо
Но что именно — мы не знаем, потому что (та-дам!) инкапсуляция.

В вызывающем коде знаем. Что именно надо предпринять, зависит от вызывающего кода, а не от вызываемого.
Это как если бы начальник вас спросил "Слетай на Луну, принеси мне лунного грунта - Это не входит в мои рабочие обязанности - Что мне делать с этим ответом?". Вы бы сказали "Что хотите, то и делайте, я же не знаю нафига вам лунный грунт". А если бы не сказали, то подумали.

код не отработал, как было задумано

Если в коде явно написано return errorCode, значит это было задумано. То есть была предусмотрена эта ситуация и написана обработка для нее.
Там может быть и return Enum.ValueA; ... return Enum.ValueB; ... на 10 значений. Какое из них не было задумано?

практически невозможно имплементировать на объектной модели, не потеряв математическое доказательство консистентности

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

Есть только два варианта разрешения конфликта: 1 блокировать монетоприёмник и считыватель карт пока турникет открыт,
1 нарушает инкапсуляцию (потроха нашего FSM экспортируются в прошивку железяк самого турникета)

Если у вас FSM только считает состояние и больше ничего не делает, то очевидно, что кто-то снаружи должен это состояние прочитать, чтобы что-то сделать.
Если он должен что-то еще делать, то вы передаете эту зависимость в конструктор, и FSM сам ее вызывает при переходе в нужное состояние.

или 2 накапливать «проходы» и не закрывать турникет
2 невозможен в ООП без плясок с бубном

Очередь и FSM это 2 разных компонента. Если вы хотите накапливать события, очередь вам нужна будет хоть с ООП, хоть не с ООП. Если не хотите, не нужна. ООП тут ни при чем, как вам надо по задаче, так и делаете. Непонятно, почему вы ждете, что FSM в стиле ООП будет вам магически сам очередь обрабатывать.

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

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

Это называется "абстракция".

Инкапсуляция должна бы запретить любое изменение внутреннего состояния сущности (объекта) извне любым способом, кроме специально разрешенных автором.

А это называется "сокрытие".

Корректное же определение инкапсуляции у Вики было до её изнасилования в 2022:

размещение в одном компоненте данных и методов, которые с ними работают

Иронично, с каким комментарием была внесена та правка:

исправил неверное определение инкапсуляции - было определено очень узко и не полно

---

кишки внутреннего устройства класса Temperature теперь торчат наружу. Снаружи придется либо поймать исключение

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

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

Как он у вас попадёт в состояние "закрыто" без сброса баланса ума не приложу. У вас инвариант сломался.

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

А в описанном примере с температурой проблемы с инкапсуляцией нет. В нем демонстрируется банальная ограниченность языка в возможности точно выразить контракт в интерфейсе сущности. То что температура не может быть ниже указанной просто будет записано в документации, как и поведение в обратном случае.

Тут даже объект не нужен, пример можно переписать как чистую функцию которая принимает температуру и считает что-то по формуле, при этом возникнет необходимость в аналогичной проверке и реакции. Не жаловаться же тогда на реализацию абстракции функциями?

Чтение статьи натолкнуло на следующее воспоминание. Люди старшего поколения рассказывали, что академик Никита Моисеев на лекциях в МФТИ говорил, что статистическая теория турбулентности пример того, когда очень хорошее знание математики не всегда приводит к хорошему результату.

Если на Силикатной улице (это в Мытищах) остановить тысячу случайных прохожих ...

Да-да, «В час жаркого весеннего заката на Патриарших прудах появилось двое граждан...».... Автор немного не добежал до Первого апреля. ;-)

Ох, уж, эти разговоры вокруг терминов!

«Незнакомец всплеснул руками.    — Какие пустяки! — сказал он. — Как много шума из-за какого-то, простите, вздора, в который никто к тому же по-настоящему не верит… Посудите сами, Александр Иванович, устраивать склоки, безобразные кинопогони, беспокоить людей из-за мифического — я не боюсь этого слова — именно мифического Белого Тезиса… Каждый трезво мыслящий человек рассматривает диван как универсальный транслятор, несколько громоздкий, но весьма добротный и устойчивый в работе. И тем более смешны старые невежды, болтающие о Белом Тезисе… Нет, я и говорить не желаю об этом диване.» — Стругацкие, «Понедельник начинается в субботу».

Поговорим, немного, о диване. Или О белом тезисе.

По моим устаревшим сведениям, инкапусляция — это попытка поместить некоторые данные и код в некую закрытую сущность (объект и/или класс) так, чтобы снаружи это всё можно было «дёргать» только через заданный интерфейс. Здесь ничего не говорится о том, что создаваемая сущность никак не зависит от других классов, или другие классы никак не зависят от данной сущности.

Посмотрите на Ваш пример с температурой. Вы используете в качестве реализации Double. Фактически, Вы задаёте некий домен (это всё восходит ещё стародавним временам, когда оформлялись технологии баз данных, и, в частности, оформлялась реляционная теория), то есть — набор или диапазон допустимых значений и оформляете этот объект как новую сущность. Это означает, что Вам нужно всюду, где встречается температура, использовать эту сущность. Вы же пишете:

Double temp = getTempFromSensor(); // from outside

Зачем это нужно? Можно было бы ожидать что-то вроде этого:

Temperature temp = sensor->value(); // from outside

Сенсор может ничего не знать про какую-то там температуру, его задача — сформировать некое текущее значение и отдать его пользователю. В то же время, класс Температура знает, что делать с этим значением.

public class Temperature {
    class const minValue=-273.15;
    Bool valid;
    Double celcius;

    public Double getCelsius() {
        return celsius;
    }
    
    public void setCelsius(Double value) {
        if (value<minValue)
          valid=false;
        else {
          celsius = value;
          valid=true;
        }
    }
}

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

public class Temperature {
    Double celcius;

    public Double getCelsius() {
        return celsius;
    }
    
    public void setCelsius(Double value) {
        celsius = value;
    }
}

А откуда вы взяли этот классический пример? Зачем температура сделана мутабельной? Получается, что например 1°C как сущность может стать внезапно 2°C. Это физически не имеет смысла.

Вроде бы во многих статьях об ООП не раз говорилось, что добавление геттеров\сеттеров не приводит к инкапсуляции автоматически. Пример выше ничем не отличается от класса с публичным полем celsius.

Логичнее сделать так:

public class Temperature {
    double celsius;

    public double getCelsius() {
        return celsius;
    }

    public double getKelvin() {
        return celsius + 273.15;
    }

    public static fromCelsius(double value) Temperature {
        if (value < −273.15) {
            throw new InvalidTemperature()
        }
        return new Temperature(value)
    }

    private Temperature(double celsius) {
        this.celsius = celsius
    } 
}

double value = getTempFromSensor(); // from outside

try {
    Temperature t = Temperature.fromCelsius(value)
    System.out.println(t.getCelsius())
} catch(InvalidTemperature e) {
    System.out.println("Sensor is broken! Call a technician.");
}

Здесь сокрыт способ хранения температуры. Можно хранить в кельвинах. Можно не double, а string. Как хотите.

Соглашусь с автором. Инкапсуляция она про отделения контракта от реализации.
В С++ частью контракта могут быть и исключения и коды ошибок и какие-то ограничения на передаваемые значения и даже ассерты внутри реализации. К сожалению, кроме как комментариями к описанию класса эти контракты описать бывает невозможно.

Ребята, одержимые функциональщиной опять пытаются доказать, что лесенки и индуский код это лучше чем код разложенный по полочкам и переиспользуемый, за счет ооп?

"Но даже в тривиальном примере выше есть проблема: нам надо бы обработать случай value < -273.15°C. И вот тут-то инкапсуляция и отыквится. Приведенный пример вроде бы можно починить: либо выбросив Exception из setCelcius, либо вернув boolean вместо void."

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

Лайфхак: пишите на Хабре что ООП это плохо и фронтендеры будут вам ставить лайки