Яка перевага об'єктно-орієнтованого програмування над процедурним програмуванням?

Я намагаюся зрозуміти різницю між процедурними мовами, такими як C, і об'єктно-орієнтованими мовами, такими як C ++. Я ніколи не використовував C ++, але я обговорював з друзями питання про те, як їх розрізнити.

Мені сказали, що C ++ має об'єктно-орієнтовані поняття, а також публічний та приватний режими для визначення змінних: у речей C немає. Мені ніколи не доводилося їх використовувати під час розробки програм у Visual Basic.NET: у чому їх переваги?

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

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

if ( login == "admin") {
    // invoke the function
}

Чому це не ідеально?

Зважаючи на те, що, мабуть, існує процедурний спосіб зробити все об'єктно-орієнтованим, чому я повинен дбати про об’єктно-орієнтоване програмування?

Усі відповіді поки що були зосереджені на темі вашого запитання, як сказано, яка "в чому різниця між c і c ++". Насправді це звучить так, ніби ви знаєте, у чому різниця, ви просто не розумієте, для чого вам знадобиться ця різниця. Тож інші відповіді намагалися пояснити ОО та інкапсуляцію.

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

Ви не розумієте призначення C ++ або OO, адже вам здається, що вашій програмі потрібно просто зберігати дані. Ці дані зберігаються у змінних. "Чому я хочу зробити змінну недоступною? Тепер я більше не можу отримати доступ до неї! Зробивши все загальнодоступним, а ще краще глобальним, я можу читати дані з будь-якого місця, і немає проблем". - І ви маєте рацію, виходячи з масштабів проектів, про які ви зараз пишете, мабуть, не так вже й багато проблем (або є, але ви просто ще не усвідомлювали їх).

Я думаю, що основне питання, на яке вам дійсно потрібно відповісти, це: "Чому я коли-небудь хотів би приховати дані? Якщо я це роблю, я не можу з цим працювати!" І ось чому:

Скажімо, ви починаєте новий проект, відкриваєте текстовий редактор і починаєте писати функції. Кожен раз, коли вам потрібно щось зберігати (щоб запам'ятати це на потім), ви створюєте змінну. Щоб зробити простішими, ви зробите ваші змінні глобальними. Ваша перша версія вашого додатка працює чудово. Тепер ви почнете додавати більше функцій. У вас є більше функцій, певні дані, які ви зберігали раніше, потрібно читати з нового коду. Інші змінні потрібно модифікувати. Ви продовжуєте писати більше функцій. Що ви, можливо, помітили (або, якщо ні, то абсолютно помітите в майбутньому), так як ваш код збільшується, вам потрібно більше і довше, щоб додати наступну функцію. І як ваш код збільшується, додавати функції стає важче і складніше, не порушуючи щось, що раніше працювало. Чому? Бо потрібно пам’ятати, що всеваші глобальні змінні зберігаються, і вам потрібно пам'ятати, де всі вони змінюються. І вам потрібно пам’ятати, яку функцію нормально викликати в точному порядку, і якщо ви будете викликати їх в іншому порядку, ви можете отримати помилки, оскільки ваші глобальні змінні ще не зовсім дійсні. Ви коли-небудь стикалися з цим?

Наскільки великі ваші типові проекти (рядки коду)? Зараз зображення проекту від 5000 до 50000 разів більше, ніж ваш. Також в ньому працюють кілька людей. Як усі в команді можуть запам'ятати (або навіть усвідомлювати), що роблять усі ці змінні?

Те, що я описав вище, є прикладом ідеально поєднаного коду. І з зорі часу (якщо припустити, що час розпочався 1 січня 1970 року), людський рід шукав способів уникнути цих проблем. Те, як їх уникнути, - це розбиття коду на системи, підсистеми та компоненти та обмеження кількості функцій, які мають доступ до будь-якої частини даних. Якщо у мене є 5 цілих чисел і рядок, які представляють собою якийсь стан, мені було б легше працювати з цим станом, якби лише 5 функцій встановили / отримали значення? або якщо 100 функцій встановлено / отримають ці самі значення? Навіть без мов OO (тобто C) люди наполегливо працювали над ізоляцією даних від інших даних та створенням чітких меж розділення між різними частинами коду. Коли проект набуває певного розміру, простота програмування стає ні, "чи можу я отримати доступ до змінної X з функції Y",

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

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

Хм ... можливо, найкраще створити резервну копію та спробувати дати деяке уявлення про основні наміри об'єктно-орієнтованого програмування. Значна частина об'єктно-орієнтованого програмування полягає в тому, щоб дозволити створювати абстрактні типи даних. Для дійсно простого прикладу, з яким ви, безсумнівно, знайомі, розгляньте рядок. У рядку зазвичай буфер містить вміст рядка, деякі функції, які можуть працювати над рядком (пошук у ньому, доступ до його частин, створення підрядків тощо). Також він (принаймні, як правило) має щось слідкуйте за (поточною) довжиною рядка та (ймовірно) розміром буфера, тому якщо (наприклад) ви збільшите розмір рядка з 1 до 1000000, він буде знати, коли йому потрібно більше пам’яті, щоб утримати більше зміст.

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

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

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

OOP проти C насправді не стосується жодної речі, про яку ви говорили. Йдеться насамперед про пакувальний код на ділянки, які не можуть / не можуть ненавмисно (а іноді навіть навмисно) впливати один на одного.

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

Добре написаний клас повинен бути трохи "острівцем довіри": Ви можете використовувати його і припускати, що він робить "правильно" і що захищає вас від загальних підводних каменів. Це робить хороший клас будівельним блоком, який набагато більше використовуватиметься як купа функцій та змінних, які можуть працювати добре, але показують вам усі їхні потворні кишки та змушують вас зрозуміти, як вони працюють разом, як їх потрібно ініціалізувати тощо. Хороший клас повинен бути схожим на USB-роз'єм, тоді як процедурне рішення - як купа дротів, мікросхем, жерсті та пайки.

Один момент, який не обговорювався в глибині, - це аспект інтерфейсу / реалізації. Інтерфейс описує поведінку, але не реалізацію. Так інтерфейс списку описує концепціюсписку та його поведінка: Ви можете очікувати таких речей, як методи додавання, видалення та розміру. Зараз існує маса різних способів реалізації цього списку, наприклад, як пов'язаний список або використання буфера масиву. Сила OO програмування полягає в тому, що за допомогою інтерфейсу ви можете міркувати про свою поведінку, не знаючи про реалізацію. Доступ до внутрішніх змінних чи методів знищив би цю абстракцію, ви не могли замінити одну реалізацію списку іншою, і ви не могли покращити існуючу реалізацію, не торкнувшись коду за допомогою класу. Це одна з головних причин, чому потрібні приватні змінні та методи: Щоб захистити внутрішні деталі реалізації, абстракція залишається цілою.

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

Існує спосіб зробити все за допомогою машини Тьюрінга або, як мінімум, мовою складання для машинного коду, до якого в кінцевому підсумку буде скомпільована програма C або C ++.

Тож різниця полягає не в тому, що може зробити код, а в тому, що можуть робити люди.

Люди роблять помилки. Багато.

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

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

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

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

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

Як багато хто сказав, що будь-яка програма після її складання перетворюється на двійковий код і, оскільки двійковий рядок може використовуватися для представлення цілого числа, будь-яка програма, врешті-решт, є лише числом. Однак визначення потрібного вам числа може бути досить важким, і саме тому вийшли мови програмування високого рівня. Мови програмування є лише моделями коду складання, який вони з часом виробляють. Я хотів би пояснити вам різницю між процедурним та програмним програмуванням за допомогою цієї дуже приємної статті про контекстне програмування http://www.jot.fm/isissue/issue_2008_03/article4/

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

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

Це дійсно дозволяє інкапсуляцію та модуляризацію.

Фігура-c, нарешті, стосується предметно-орієнтованого програмування, розширює об'єктно-орієнтований метод відправки ще на один вимір.

Сподіваємось, це допомогло вам подумати в OOP з іншого погляду.

(+1) Задаючи питання про щось, чого ви не розумієте, його користь, навіть якщо це звучить нерозумно.

Різниця полягає в об'єктно-класовому програмуванні. "Звичайна С", працює з даними та функціями. "C ++" додає поняття "об'єкт і класи", а також кілька пов'язаних із ними вторинних понять.

Однак я закликаю розробників вивчити "Звичайний C" перед "C ++". Або "Процедуальний паскаль" перед "Об'єктом Паскаль".

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

Наприклад, старі вчителі, які не отримують ОО, а викладають лише "Звичайну структуровану С".

Або "хіпстерські" викладачі, які викладають тільки ОО, але не "Звичайну С", тому що "вам це не потрібно". Або і те й інше, не піклуючись про порядок навчання.

Я радше думаю, що студентів слід навчати як "Структурованій рівнині С", так і "Об'єктно-орієнтованій С (С ++)". Спочатку "Звичайна С" та "С ++", пізніше.

У реальному світі потрібно вивчити обидві парадигми (плюс інші парадигми, як-от "функціональні").

Мислення структурованих програм як великого, єдиного "об'єкта", може допомогти.

Ви також повинні робити акцент у просторах імен ("модулів"), в обох мовах багато вчителів просто ігнорують це, але, що важливо.

Одним словом, управління проектами. Я маю на увазі те, що C ++ допомагає мені виконувати правила того, як мій код використовується іншими. Працюючи над проектом 5,5 мільйонів ліній, мені здається, що об’єктно-орієнтоване програмування дуже корисне. Ще одна перевага - компілятор, який змушує мене (і всіх інших) дотримуватись певних правил і виявляти незначні помилки під час компіляції. Усі теоретичні переваги є і там, але я просто хотів зосередитись на повсякденних практичних речах. Зрештою, все це компілюється в машинний код.

Об'єктно-орієнтоване програмування - це процедурне програмування, з полями.

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

В OO у вас є багато коробок, багато штатів, і в міру зростання проекту коробки зростають мало, а кількість коробок зростає значно.

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

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

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

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

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

Це також виграє PP дуже далеко, тому що ви можете розвивати проект набагато довше, оскільки немає більше статусу XXXXXXXL.

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

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

І ви отримуєте 100% надійне тестування одиниць безкоштовно.

І вам не доведеться писати "приватний статичний фінал of_doom genius awesome string_1".

І ви отримуєте паралелізм безкоштовно.

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

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