Чи підтримують парадигми, що не входять в ООП, такі поняття, як капсулювання?

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

Мене змушує задуматися, що з інкапсуляцією та іншими принципами OOP? Вони помиляються?

Хіба що OOP застосовується неправильно? Наприклад, Алан Кей відзначається тим, що говорить в основній записці OOPSLA'97: "Я винайшов термін, орієнтований на об'єкт, і можу сказати вам, що я не мав на увазі C ++".

Джо Армстронг - "Об'єкти пов'язують функції та структури даних разом у нероздільних одиницях. Я думаю, що це принципова помилка, оскільки функції та структури даних належать до абсолютно різних світів".

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

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

Однак у реальному світі речі не дуже нарізані та сухі, тому два розробники дадуть дві різні відповіді. Можливо, вони є експертами з різних мов, які по-різному виражають поняття OOP. Мовні парадигми, як правило, перетинаються. Останній гнів станом на 2013 рік або більше - це функціональне програмування на об'єктно-орієнтованих мовах через закриття чи лямбда. Об'єктно-орієнтована чи функціональна Java 8? Я б назвав це об'єктно-орієнтованим з тиском функціоналу. Хтось ще може описати це інакше.

Хіба що OOP застосовується неправильно?

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

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

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

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

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

Мене змушує задуматися, що з інкапсуляцією та іншими принципами OOP? Вони помиляються?

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

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

Хіба що OOP застосовується неправильно? Наприклад, Алан Кей відзначається тим, що говорить в основній записці OOPSLA'97: "Я винайшов термін, орієнтований на об'єкт, і можу сказати вам, що я не мав на увазі C ++".

Безумовно, OOP часто застосовується неправильно багатьма людьми, але я впевнений, що це стосується і FP. І я був би здивований, якби Джон Мак Керті (дизайнер Lisp) мав на увазі щось на кшталт Javascript, коли він думав про функціональне програмування (пощади мені, не плач мені занадто сильно для цього порівняння ;-)

Джо Армстронг - "Об'єкти пов'язують функції та структури даних разом у нероздільних одиницях. Я думаю, що це принципова помилка, оскільки функції та структури даних належать до абсолютно різних світів".

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

Звичайно:

struct Foo
{
    string bar;
    int bux;
}

Я знаю, що ти скажеш: "Але це також не інкапсулює поведінку!" Ну, я з Джо Армстронгом на цьому: ви можете писати цілі програми або операційні системи, не вимагаючи об'єктів першого класу. Linux це доводить.

Програмісти Javascript звичайно інкапсулюють стан та поведінку у функціях та закриттях, а не у класах.

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

Перше визначення, яке ви збираєтесь знайти, - це

Інкапсуляція - це концепція, яка поєднує в собі дані та функції, що управляють даними ...

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

Але я заперечую, що це не головна мета інкапсуляції, оскільки це визначення продовжується:

... і це захищає і від втручання, і від неправильного використання.

Вікіпедія також погоджується з цим:

Мовний механізм обмеження прямого доступу до деяких компонентів об'єкта.

Але тепер нам потрібно запитати, що розуміється під "втручанням та неправильним вживанням" і чому слід обмежувати прямий доступ до даних. Я вважаю, що це дві причини.

По-перше, обмеження обсягу, в якому дані можуть бути мутовані, є в інтересах розробника. Шлях занадто часто виникає необхідність мати логіку до / після встановлення значення. А наявність обмеженої кількості місць, де можна встановити значення, є надзвичайно цінною. На мовах OOP це можна зробити за допомогою класів. У "змінних" функціональних мовах закриття служать одній цілі. А оскільки ми знаємо класи = закриття , це навіть сперечається, ніж змінні функціональні мови відрізняються "парадигмою" до OOP.

А як щодо незмінних мов? У нього немає проблеми з мутуванням змінних. Тут виникає друга проблема: функції зв’язування та дані дозволяють утримувати ці дані у стані, що є дійсним. Уявіть, у вас незмінна структура Email. Ця структура має єдине stringполе. У нас є вимоги, що якщо у вас є значення типу, Emailто це поле містить дійсну адресу. У капсуляції OOP це легко зробити, оголосивши це поле private, надавши лише Getметод і маючиconstructor methodщо вдається лише в тому випадку, якщо передано в рядку є дійсною адресою. Аналогічна річ із закриттями. Тепер для непорушної мови потрібно було б сказати, що структура може бути ініціалізована лише через певну функцію, і така функція може вийти з ладу. І я не знаю жодної мови, яка відповідала б цим критеріям (можливо, хтось у коментарях може мене просвітити).

Останнє питання - що розуміється під мовою "підтримуючої" інкапсуляції. З одного боку є мови, які дозволяють примусово виконувати інкапсуляцію, так що код не складеться, якщо інкапсуляція порушена. З іншого боку, мова може забезпечити інкапсуляцію, але вона не виконує її, залишаючи розробнику самостійно їх застосовувати. У другому випадку може працювати будь-яка мова, що має структури та функції. Динамічні мови та Haskell приходять до тями. І я б сказав, що з іншого боку спектра не так багато мов. Навіть C #, який дуже добре застосовує інкапсуляцію для своїх об'єктів, можна обійти за допомогою відображення. Але бачачи, що в C # це вважатиметься масивним кодовим запахом, і жоден здоровий розробник C # не зробить цього охоче.