OOP проти функціонального програмування проти процедурного [закрито]

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

Приклади архітектури оцінені!

Всі вони хороші по-своєму - Просто різні підходи до одних і тих же проблем.

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

У об'єктно-орієнтованому стилі дані, як правило, несуть із собою набір функцій.

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

Звичайно, сама мова впливає лише на те, якому стилю віддається перевага. Навіть на чистофункціональній мові, як Haskell, ви можете писати в процедурному стилі (хоча це сильно не відштовхується), і навіть на процедурній мові, як C, ви можете програмувати в об'єктно-орієнтованому стилі (наприклад, в GTK + і API EFL).

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

Вибір, який ви використовуєте, - це просто те, що має більше сенсу для вашого проекту та абстракцій, які підтримує ваша мова.

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

Наприклад, якщо ви робите відеоігри, є більше хороших прикладів коду та SDK в C ++, тому вам, мабуть, краще з цим. Для невеликого веб-додатка є кілька чудових фреймворків Python, PHP та Ruby, які дозволять вам швидко працювати. Java є прекрасним вибором для великих проектів через перевірку часу компіляції та корпоративні бібліотеки та платформи.

Бувало так, що стандартні бібліотеки для різних мов були досить малі та легко копіювалися - C, C ++, Assembler, ML, LISP тощо. Поставились з основами, але, як правило, курячі, коли мова зайшла про стандартизацію речей як мережеві комунікації, шифрування, графіка, формати файлів даних (включаючи XML), навіть основні структури даних, такі як збалансовані дерева та хештелі!

Сучасні мови, такі як Python, PHP, Ruby та Java, тепер мають набагато пристойнішу стандартну бібліотеку і мають багато хороших сторонніх бібліотек, якими ви можете легко користуватися, завдяки великій частині завдяки їх прийняттю просторів імен, щоб бібліотеки не стикалися між собою, і збирання сміття для стандартизації схем управління пам’яттю бібліотек.

Ці парадигми не повинні бути взаємовиключними. Якщо ви подивитесь на python, він підтримує функції та класи, але в той же час все є об'єктом, включаючи функції. Ви можете змішати і співставити функціональний / oop / процедурний стиль все в одному коді.

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

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

У python функція є першокласним громадянином, але вона може містити довільну кількість тверджень. Таким чином, ви можете мати функцію, яка містить процедурний код, але ви можете передавати її навколо, як і функціональні мови.

Те саме стосується і ООП. Мова, як Java, не дозволяє писати процедури / функції поза класом. Єдиний спосіб передати функцію навколо - це обернути її в об'єкт, який реалізує цю функцію, а потім передавати цей об’єкт навколо.

У Python у вас немає цього обмеження.

Для GUI я б сказав, що об'єктно-орієнтована парадигма дуже добре підходить. Вікно - це об'єкт, текстові поля - це об'єкти, а кнопка «Гаразд» - теж одна. З іншого боку, такі речі, як обробка рядків, можна зробити з набагато меншими накладними витратами і, отже, більш простою за допомогою простої процедурної парадигми.

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

Щоб відповісти на ваше запитання, нам потрібні два елементи:

1. Розуміння характеристик різних архітектурних стилів / моделей.
2. Розуміння характеристик різних парадигм програмування.

Перелік стилів / візерунка архітектури програмного забезпечення показаний у статті про архітектуру програмного забезпечення про у Wikipeida. І ви можете легко досліджувати їх в Інтернеті.

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

Я думаю, вам слід спробувати прочитати історію кожної парадигми і побачити, чому люди її створюють, і ви можете їх легко зрозуміти.

Розуміючи їх обоє, ви можете зв’язати елементи стилів / моделей архітектури з парадигмами програмування.

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

Один з моїх друзів пише графічний додаток, використовуючи NVIDIA CUDA . Застосування дуже добре поєднується з парадигмою OOP, і проблема може бути акуратно розкладена на модулі. Однак для використання CUDA потрібно використовувати C, який не підтримує успадкування . Тому потрібно бути розумним.

а) Ви розробляєте розумну систему, яка певною мірою буде імітувати спадщину. Це можна зробити!

i) Ви можете використовувати a гака , яка очікує, що кожна дитина C батьківського P матиме певний перебір функції F. Ви можете змусити дітей реєструвати їхні скасування, які зберігатимуться та викликатимуться за потреби.

ii) Ви можете використовувати struct вирівнювання пам'яті функцію щоб передати дітей батькам.

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

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

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