З мого (правда, обмеженого) впливу функціональних мов програмування, таких як Clojure, здається, що інкапсуляція даних відіграє менш важливу роль. Зазвичай різні типові типи, такі як карти або набори, є бажаною валютою представлення даних над об'єктами. Крім того, ці дані, як правило, незмінні.
Наприклад, ось одна з найвідоміших цитат «Rich Hickey of Clojure», в інтерв’ю з цього приводу :
Фогус: Слідуючи цій ідеї, деякі люди дивуються тому, що Clojure не займається інкапсуляцією прихованих даних щодо її типів. Чому ви вирішили відмовитися від приховування даних?
Хікі: Давайте будемо зрозуміти, що Clojure сильно підкреслює програмування на абстракції. Але в якийсь момент комусь потрібно буде мати доступ до даних. І якщо у вас є поняття "приватне", вам потрібні відповідні поняття привілей та довіри. А це додає цілу тону складності та малої вартості, створює жорсткість у системі та часто змушує речі жити там, де вони не повинні. Це на додаток до іншої втрати, яка виникає, коли проста класифікація кладеться в класи. Наскільки дані непорушні, мало шкоди може надати доступ, окрім того, що хтось може залежати від чогось, що може змінитися. Ну добре, люди роблять це весь час у реальному житті, і коли все змінюється, вони пристосовуються. І якщо вони раціональні, вони знають, коли вони приймають рішення, ґрунтуючись на чомусь, що може змінитись, що, можливо, в майбутньому їм потрібно буде адаптуватися. Отже, це рішення щодо управління ризиками, я думаю, що програмісти повинні вільно приймати. Якщо люди не мають сенсу бажати запрограмувати абстракції та бути обережними, коли вони будуть брати подробиці щодо впровадження, вони ніколи не стануть хорошими програмістами.
Походить із світу ОО, це, здається, ускладнює деякі закріплені принципи, які я навчився роками. До них можна віднести приховування інформації, закон про деметер та єдиний принцип доступу. Загальний потік, який полягає в тому, що інкапсуляція дозволяє нам визначити API для того, щоб інші знали, що вони повинні і чого не повинні торкатися. По суті, створення договору, який дозволяє обслуговуючому персоналу коду вільно вносити зміни та переробляти, не переживаючи про те, як це може ввести помилки в код споживача (принцип відкритого / закритого). Він також забезпечує чистий кураторний інтерфейс для інших програмістів, щоб знати, які інструменти вони можуть використовувати для отримання або надбудови цих даних.
Коли дозволено отримати доступ до даних, цей контракт API розірваний, і всі ці переваги щодо капсуляції, схоже, втрачаються. Крім того, здається, що суворо незмінні дані роблять проходження навколо доменних структур (об'єктів, структур, записів) набагато менш корисним у сенсі представлення стану та набору дій, які можна виконати в цьому стані.
Як функціональні кодові бази вирішують ці проблеми, які, здається, виникають, коли розмір кодової бази зростає величезним чином, що API потрібно визначити і багато розробників залучені до роботи з конкретними частинами системи? Чи є приклади такої ситуації, які демонструють, як це обробляється в таких типах кодових баз?
Also, strictly immutable data seems to make passing around domain-specific structures (objects, structs, records) much less useful in the sense of representing a state and the set of actions that can be performed on that state.Не зовсім. Єдине, що змінюється - це те, що зміни закінчуються на новому об’єкті. Це величезна виграш, коли мова йде про міркування про код; передача змінних об'єктів навколо означає, що потрібно відслідковувати, хто може їх мутувати, проблема, яка збільшується з розміром коду.