Існує класична стаття під назвою "Критерії, які потрібно використовувати в розкладанні систем на модулі", яку я тільки що прочитав вперше. Для мене це має сенс, і, мабуть, одна з тих статей, на яких базувався ООП. Її висновок:

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

На мою неосвічену і недосвідчену думку, функціональне програмування відповідає точно протилежним порадам цієї статті. Я розумію, що функціональне програмування робить потік даних ідіоматичним. Дані передаються від функції до функції, причому кожна функція ретельно усвідомлює дані та "змінює їх" по дорозі. І я думаю, що я бачив, як Річ Хікі розмовляв, коли він розповідає про те, як переховування даних є завищеним чи непотрібним чи іншим, але я не можу точно згадати.

1. Спершу я хочу знати, чи моя оцінка правильна. Чи не узгоджується парадигма ФП та ця стаття по-філософськи?
2. Якщо припустити, що вони не згодні, як ПП "компенсує" відсутність даних про приховування даних? Можливо, вони жертвують даними, ховаючи дані X, Y і Z. Я хотів би знати міркування, чому X, Y і Z вважаються більш корисними, ніж приховування даних.
3. Або, якщо припустити, що вони не згодні, можливо, FP вважає, що приховування даних погано. Якщо так, то чому він вважає, що приховування даних є поганим?
4. Припускаючи, що вони згодні, я хотів би знати, що таке FP-реалізація приховування даних. Очевидно це бачити в OOP. Ви можете мати privateполе, до якого не може отримати доступ ніхто поза класом. Очевидною аналогією мені це у FP немає.
5. Я відчуваю, що є інші питання, які мені слід задавати, але я не знаю, що мені слід задавати. Не соромтеся відповідати і на них.

Оновлення

Я знайшов цю розмову про Ніла Форда, яка має в ній дуже релевантний слайд. Я вставлю сюди скріншот:

Стаття, яку ви згадуєте, стосується модульності в цілому, і вона однаково стосуватиметься структурованих, функціональних та об'єктно-орієнтованих програм. Я чув про цю статтю раніше від когось, хто був великим хлопцем з ООП, але я читав це як статтю про програмування взагалі, а не щось специфічне для ООП. Існує відома стаття про функціональне програмування, чому питання функціонального програмування має значення , а в першому реченні висновку зазначено "У цій роботі ми доводили, що модульність є запорукою успішного програмування". Тож відповідь на (1) - ні.

Добре розроблені функції не припускають більше своїх даних, ніж потрібно, тому частина про "глибоко усвідомлених даних" неправильна. (Або принаймні настільки ж неправильно, як це було б у OOP. Ви не можете програмувати суворо на високому рівні абстрагування і ігнорувати всі деталі назавжди в будь-якій парадигмі. Зрештою, деякій частині програми насправді потрібно знати про конкретні деталі даних.)

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

Редагувати: Я знайшов відповідну цитату з інтерв'ю з Річком Хікі .

Фогус: Слідуючи цій ідеї, деякі люди дивуються тому, що Clojure не займається інкапсуляцією прихованих даних щодо її типів. Чому ви вирішили відмовитися від приховування даних?

Хікі: Давайте будемо зрозуміти, що Clojure сильно підкреслює програмування на абстракції. Але в якийсь момент комусь потрібно буде мати доступ до даних. І якщо у вас є поняття "приватне", вам потрібні відповідні поняття привілей та довіри. А це додає цілу тону складності та малої вартості, створює жорсткість у системі та часто змушує речі жити там, де вони не повинні. Це на додаток до іншої втрати, яка виникає, коли проста класифікація кладеться в класи. Наскільки дані непорушні, мало шкоди може надати доступ, окрім того, що хтось може залежати від чогось, що може змінитися. Ну добре, люди роблять це весь час у реальному житті, і коли все змінюється, вони пристосовуються. І якщо вони раціональні, вони знають, коли вони приймають рішення, ґрунтуючись на чомусь, що може змінитись, що, можливо, у майбутньому їм потрібно буде адаптуватися. Отже, це рішення щодо управління ризиками. Я думаю, що програмісти повинні вільно приймати. Якщо люди не мають сенсу бажати запрограмувати абстракції і бути обережними щодо того, щоб одружитися з деталями реалізації, вони ніколи не стануть хорошими програмістами.

... і, ймовірно, одна з тих статей, на яких базувався ООП.

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

Спершу я хочу знати, чи моя оцінка правильна. Чи не узгоджується парадигма ФП та ця стаття по-філософськи?

Ні. Крім того, на мій погляд, ваш опис того, як виглядає програма FP, не відрізняється від будь-якої іншої, яка використовує процедури чи функції:

Дані передаються від функції до функції, причому кожна функція ретельно усвідомлює дані та "змінює їх" по дорозі.

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

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

Припускаючи, що вони згодні, я хотів би дізнатися, що таке FP-реалізація приховування даних. Очевидно це бачити в OOP. Ви можете мати приватне поле, до якого не може отримати доступ ніхто поза класом. Очевидною аналогією мені це у FP немає.

Що стосується даних, ви можете розробити вилучення даних та абстрагування типів даних за допомогою FP. Будь-яка з них приховує бетонні конструкції та маніпуляції з цими бетонними конструкціями, використовуючи функції як абстракції.

EDIT

Тут зростає кількість тверджень, що стверджують, що "приховування даних" в контексті ПП не є настільки корисним (або OOP-ish (?)). Отже, дозвольте мені навести тут дуже простий і зрозумілий приклад з SICP:

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

(define my-rat (cons 1 2)) ; here is my 1/2 

Якщо ігнорувати абстракції даних, швидше за все , ви отримаєте чисельник і знаменник , використовуючи carі cdr:

(... (car my-rat)) ; do something with the numerator

Дотримуючись такого підходу, всі частини системи, що маніпулюють раціональними числами, будуть знати, що раціональне число є cons- вони будуть consнумерувати для створення раціональних даних і витягувати їх за допомогою операторів списку.

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

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

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

• (make-rat <n> <d>)повертає раціональне число, чисельником якого є ціле число, <n>а знаменником якого є ціле число <d>.

• (numer <x>)повертає чисельник раціонального числа <x>.

• (denom <x>)повертає знаменник раціонального числа <x>.

і система більше не буде (і більше не повинна) знати про те, з чого складається раціоналізатор. Це відбувається тому cons, carі cdrїм невластиві раціональні числа, але make-rat, numerі denom це . Звичайно, це легко може бути системою ПП. Отже, "приховування даних" (в даному випадку більш відоме як абстракція даних або зусилля по інкапсуляції уявлень і конкретних конструкцій) є відповідною концепцією і методом, широко використовуваним і дослідженим, чи то в контексті ОО, функціонального програмування чи що завгодно.

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

• Змінність: чи потрібно внести необхідні зміни на локальному рівні або поширити через систему.
• Самостійний розвиток: наскільки дві частини системи можна розвивати паралельно.
• Дослідність: яка частина системи потрібна, щоб знати, щоб зрозуміти одну з її частин.

Наведений вище приклад взятий з книги SICP, тому для повного обговорення та представлення цих понять у книзі я настійно рекомендую переглянути розділ 2 . Я також рекомендую ознайомитись з абстрактними типами даних у контексті FP, що вносить інші питання до таблиці.

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

map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs

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

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

Я збираюся вдарити тут по кінцівці і сказати, що концепція просто не стосується ПП, як це є в ОО.

tl; dr; Сенс приховування даних полягає в тому, щоб забезпечити збереження відповідальності там, де вони повинні бути, і у вас немає сторонніх акторів, які б возилися з даними, на які вони не знають. У програмі FP дані генеруються виразами, і таким чином ви не можете возитися з даними, оскільки це не змінні властивості настільки, як складові обчислення, що повністю змінює правила гри.

З мого досвіду з FP; які, мабуть, незначні, я схильний знаходити один різкий контраст з ОО в тому, що позначає добре / загальне моделювання даних.

Цей контраст полягає в тому, що в OO взагалі ви моделюєте речі для представлення своїх даних. Обов'язкова аналогія автомобіля:

ОО

• У вас є автомобільний об'єкт, який правильно приховує деталі щодо автомобіля, такі як реалізація змінного струму (це приводиться в дію на ремені або нагнітається тиском повітря? Споживачі не повинні знати, тому приховуйте це).
• Цей автомобільний об’єкт має безліч властивостей і методів, які визначають усі факти про автомобіль, а також способи роботи з автомобілем.
• Цей автомобільний об'єкт має властивості, які є компонентами автомобіля, які надалі приховують від загального автомобіля їх конкретні реалізації, а також їхні дані, що дозволяють взаємозамінювати компоненти автомобіля.

Тут слід зауважити, коли ви моделюєте речі у форматі OO, все полягає у поданні речей як Data. У вас є об'єкти з властивостями, багато з цих властивостей є об'єктами з більшою кількістю властивостей. У вас є кілька методів, які тут і там прикріплені до цих об'єктів, але все, що вони насправді роблять, - це, як правило, таким чином переміщувати властивості об'єктів, і це, знову ж таки, дуже орієнтоване на дані моделювання; тобто ви моделюєте свої дані для взаємодії з акцентом на їх структуруванні, щоб зробити доступними всі точки ваших даних, щоб споживачі могли змінювати дані таким чином.

ПП

• Ви маєте велику кількість обчислень, які дозволяють описати поведінку
• Ці вирази поведінки пов'язані таким чином, що можна перекласти так, як поведінка автомобілів пов'язана з іншим, наприклад, автомобіль, який має прискорення / уповільнення, є дві поведінки, які протистоять іншим подібним чином.

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

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

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

Повертаючись до питання, що говорить FP про приховування даних, оцінює це чи не погоджується з ним чи ні?

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

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

Як це так? Подумайте про приємний інтерфейс ОО, який приховує основні дані - можливо, колекції (я намагаюся вибрати щось майже всюдисуще). Можливо, вам не знадобиться знати базовий тип об'єктів у колекції або тип об'єкта, що реалізує колекцію, доки ви знаєте, що колекція реалізує, скажімо, IEnumerable. Отже, у вас є приховування даних.

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

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

Отже, що стосується вашого пункту 1, я не думаю, що ПП та стаття дійсно не згодні. Я не думаю, що ваша характеристика FP, що не приховує дані, є правильною. Можна, звичайно, реалізувати дизайн, який автор віддав перевагу на FP.

Щодо пункту 4 (2 та 3) немає сенсу відповідати з огляду на те, що я сказав у пункті 1, він змінюється. Він також різниться в мовах ОО, і в багатьох приватних областях вони є приватними за умовами, а не застосовуються мовою.

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

Спершу я хочу знати, чи моя оцінка правильна. Чи не узгоджується парадигма ФП та ця стаття по-філософськи?

Дизайн ПП дуже орієнтований на потік даних (що IMHO не так вже й погано, як це може означати стаття). Якщо це повна "незгода", то можна сперечатися.

Якщо припустити, що вони не згодні, як ПП "компенсує" відсутність даних про приховування даних? Можливо, вони жертвують даними, ховаючи дані X, Y і Z. Я хотів би знати міркування, чому X, Y і Z вважаються більш корисними, ніж приховування даних.

ІМХО це не компенсує. Дивись нижче.

Або, якщо припустити, що вони не згодні, можливо, FP вважає, що приховування даних погано. Якщо так, то чому він вважає, що приховування даних є поганим?

Я не думаю, що більшість користувачів FP або дизайнерів не відчувають себе та думають таким чином, див. Нижче.

Припускаючи, що вони згодні, я хотів би дізнатися, що таке FP-реалізація приховування даних. Очевидно це бачити в OOP. Ви можете мати приватне поле, до якого не може отримати доступ ніхто поза класом. Очевидною аналогією мені це у FP немає.

Тут є сенс - ви, напевно, бачили стільки систем OOP, реалізованих нефункціонально, що ви вважаєте, що OOP є нефункціональним. І це помилка, IMHO OOP і FP - це здебільшого ортогональні концепції, і ви можете ідеально побудувати функціональні системи OO, що дає вам очевидну відповідь на ваше запитання. Класична реалізація "об'єкта" у FP здійснюється за допомогою закриття , і якщо ви хочете, щоб об'єкти використовувались у функціональній системі, ключовим моментом є створення їх непорушних.

Отже, для створення більших систем IMHO ви можете створювати модулі, класи та об'єкти, використовуючи концепції OO, саме так, як описано у статті "Модуляризація 2" у статті, не виходячи з "FP шляху". Ви будете використовувати модульну концепцію вашої улюбленої мови FP, зробите лише всі свої об'єкти незмінні та використовуватимете «найкраще з обох світів».

TL; DR : Ні

Філософсько не погоджується парадигма ФП та ця стаття ?.

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

Процедурне програмування набагато ближче до кодування блок-схеми, ніж функціональне програмування. Звідси випливає, що перетворення, що виникають, і кодують ці перетворення в процедури, які виконуються в порядку, точно так само, як описаний потік у схемі потоків.

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

Приховування даних

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