Що зробило об’єктно-орієнтоване програмування успішним? [зачинено]


17

Яка така особливість, на вашу думку, зробила об’єктно-орієнтоване програмування настільки успішним?

  1. Повідомлення проходить
  2. Спадщина
  3. Поліморфізм
  4. Інкапсуляція

Або якусь іншу функцію, яку ви хочете представити.

Також я хотів би знати, що полягає в зв'язку між абстрактним типом даних та об'єктно-орієнтованим програмуванням?


популярні та успішні не є синонімами
kevin cline

Відповіді:


76

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

Людський мозок може вмістити лише стільки понять за один раз - часто згадується межа запам'ятовування 7 +/- 2 незалежних предметів.

Коли я працюю над системою 600клок на роботі, я не можу одразу тримати всю цю річ у голові. Якби мені довелося це робити, я обмежувався б роботою над значно меншими системами.

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

Усі важливі поняття ОО надають способи управління складністю.

Інкапсуляція - дозвольте мені мати справу із зовнішнім API, який надає мені різні сервіси, не переживаючи, як ці сервіси реалізовані.

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

Склад - дозвольте повторно використовувати компоненти, які вже були побудовані в нових комбінаціях

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

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

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

Принцип заміщення Ліскова - не давайте ставити пастки один одному, вводячи непарні залежності

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

Ін'єкція залежностей - давайте переймемо композицію на наступний рівень і зібрати компоненти разом набагато пізніше.

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


6
+1. Я можу проголосувати лише один раз, прикро, що цього заслуговує більше.
Річард

1
Це є наслідком цього, шкода, що я не можу зараз знайти посилання, але я спробую пам'ятати, щоб переглянути його та відредагувати коментар. Таким чином, дослідження практики перегляду коду виявили, що огляди коду, як правило, займають більше часу, щоб знайти помилки в коді OO, ніж процедурний код, оскільки потік стрибкує більше в коді OO. Такі практики, як TDD та парне програмування, це пом'якшують, але це все ж цікавий (і на мене, несподіваний) результат.

5
Це може бути ідеальною відповіддю - інформація повна, але досить коротка, щоб читачеві не довелося читати роман. Браво
Тім Класон

@ Грахам Лі: Мені було б цікаво прочитати це дослідження.
Френк Ширар


13

Графічний інтерфейс користувача. Наприкінці вісімдесятих, на початку дев'яностих, коли Macs, Amigas, Atari STs, Windows та GEM почали замінювати інтерфейси, засновані на символах, стало очевидним, що такі мови, як C, не дуже підходять для написання програм GUI. У той час як традиційна обробка даних розглядається як схема "вхідних даних -> обробка -> вихідних даних", яка також може бути виконана на процедурній мові, окрім особливостей OO, це було зручно для управління властивою складністю графічного інтерфейсу.


1
+1 для згадування програм GUI. Орієнтація на об'єкти була інструментом, який дозволив реалізувати графічні інтерфейси, які в іншому випадку (з процедурним кодом) були досить важкими для управління.
Джорджіо

7

Приховування даних, надане інкапсуляцією.


Це відповідь? ADT надають приховування даних (саме тому їх називають "абстракціями даних")
Frank Shearar

@Frank, Він попросив конкретні особливості, і коли я написав цю відповідь, залишився лише один, і я намагався не дублювати.

Досить справедливо, але капсулювання не є специфічним для ОО. Я повинен сам це перевірити, але я впевнений, що ми робили інкапсуляцію задовго до ОО.
Френк Ширар

1
@Frank, я погоджуюся, що це не характерно для ОО, це лише одна з його головних особливостей.

Це справедливо для більшості OOPL, але не для всіх. CLOS - помітний виняток.
Френк Ширар

7

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


6

Я вважаю, що спадщина є найважливішим моментом ООП.

[з розробки ігор] Ви можете створити щось на кшталт класу Dravable з методами візуалізації та атрибутами та створити клас Spaceship and Planet, який успадковується від Dravable. Візьміть усі об'єкти з цих [та інших дітей-спрайтів], киньте в dravableObjArray і просто зателефонуйте методу малювання для кожного об'єкта. Вам просто потрібно знати, що це Dravable.


2
Дійсно ?? Поліморфізм ШЛЯХО більш важливий і не потребує успадкування (з теоретичної точки зору).
Томас Едінг

Навіть не потрібно віртуальних функцій, просто використовуйте покажчики функцій.
Кальмарій

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


2

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

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


Можливо, це пов'язано з більшим досвідом роботи з процедурними процедурами, але після використання обох методів я все ще вважаю процедурні більш інтуїтивними, ніж OOP. Мені все ж подобаються хороші частини обох стилів.
Juha Untinen

1

Тут не раз просили " ADT vs об’єкти ". Однорядкова відповідь - "ADT і об'єкти є зворотними один до одного - те, що один акуратно резюмує, інший не може; кожен дозволяє гнучкість по-різному".

Для більш тривалої відповіді див. Статтю Вільяма Кука " Розуміння абстракції даних", Переглянуте . Якщо коротко, об'єкти дозволяють легко використовувати декілька реалізацій / представлень якоїсь даної дати (те, що схоже на список, може бути масивом, деревом з самоврівноваженням, або ...), але ускладнює додавання нових операцій (тому що ви потрібно додати цю нову операцію до кожного з ваших представлень), тоді як ADT дозволяє легко додавати нові операції для вашого типу даних, але ускладнює наявність декількох реалізацій.

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


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

Твій ОО не обов'язково є моїм ОО. І більшість мов, які називаються ОО, не є, за визначенням Алана Кей. Я забуваю точну цитату, але Кей сказав, що для Smalltalk важливо не те, що було важливим, а передача повідомлень (і це найбільше пропустило цю точку).
Френк Ширар

@Jonas Я думаю, перечитуючи запитання і свою відповідь, що я наполовину кажу "OO не є успішним, оскільки так мало мов це правильно". Але такі речі я кажу лише тоді, коли одягаю вогнестійкий костюм.
Френк Шірар

0

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

ADT - це можна мати навіть у не об’єктно-орієнтованих мовах, таких як Pascal. Стек або черга - приклади ADT.


"ADT - ви можете це мати навіть у не об'єктно-орієнтованих мовах, таких як Pascal. Стек або черга - приклади ADT.": True. Але OOP полегшує визначення інтерфейсу ADT та забезпечує іншу взаємозамінну реалізацію (інтерфейс / абстрактний клас <---> підкласи / конкретні класи). Наскільки я знаю, це не так просто в Паскалі.
Джорджо

0

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

як ур питання про 4 особливості OOP, так що ви можете сказати

  1. Спадщина і 4. Інкапсуляція - це найважливіші особливості, а інші два дуже необхідні для досягнення перших двох

так 1. Передача повідомлень і 3. Поліморфізм насправді підтримує 2. Успадкування і 4. Інкапсуляція.

  1. Спадщина та 4. Інкапсуляція є ключовими для успіху для ООП

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

-1

На мою думку, останні три функції є найважливішими, що вплинули на широке використання OOP:

2. Inheritance
3. Polymorphism
4. Encapsulation

Редагувати: Іншим моментом буде середовище розробки IDE та графічного інтерфейсу, як Visual studio та Eclipse. Коли вони застосовують мови OOP, таким чином, все більше і більше конструкцій схиляються до OOP.

І звичайно принципи SOLID - це те, що робить програмні продукти ROCK надійними :)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.