Співвідношення між орієнтацією об'єкта та алгоритмами

Коли я читаю деякі підручники з алгоритмами, вони сповнені розумних процедур для деяких проблем (сортування, найкоротший шлях) або якихось загальних методів (рекурсивні алгоритми, ділення та перемоги, динамічне програмування ...). Я знайшов там мало слідів об’єктно-орієнтованого програмування; (Чому вони більш орієнтовані на процедури?).

Тоді я думав:

• Яке співвідношення між алгоритмами та OOP? Це дві незалежні теми?
• Чи є якісь проблеми, які може бути представлений і вирішений тільки ООП?
• Як OOP може допомогти алгоритмам? Або в якому напрямку це може вплинути?

Спочатку давайте визначимо, що ми маємо на увазі під ООП. Під ООП я маю на увазі насамперед:

• Капсулювання та приховування деталей у класі.
• Поліморфізм поведінки шляхом успадкування та віртуальних методів.

Тепер, щоб відповісти на ваше запитання:

Яке співвідношення між алгоритмами та OOP? Це дві незалежні теми?

Так.

Чи є якісь проблеми, які тільки може бути представлений і вирішений OOP?

Ні. Основний OOP пропонує зручність та можливість міркувати про код програміста. Це не збільшує вашу виражальну силу.

Як OOP може допомогти алгоритмам? Або в якому напрямку це може вплинути?

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

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

Чому підручник алгоритмів більше орієнтований на процедури?

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

Алгоритми та ООП - це два розрізнені терміни, які мають спільне лише те, що вони є CS -термінами. Просто - алгоритм схожий на рецепт приготування : щоб зробити х, вам потрібні наступні інгредієнти і зробити крок 1,2,3,4,5,6 ... тоді ви готуєте страву.

Тим НЕ менше, це здається природним , придатні для algortihms бути описано в процедурному способі. Процедурний означає не що інше, як: спочатку зробіть x, а потім зробіть y .

Поширена проблема: »Як сортувати набір x ?«. Просте для розуміння рішення bubble-sort:

1. Повторіть набір з останнього елемента до тих пір, поки ви не дійшли до першого елемента і під час повторення
2. Почніть другу ітерацію від початку до поточного елемента першої ітерації та
3. Порівняйте поточний елемент (2) з його наступником
4. Якщо більше, поміняйте місцями

Це алгоритмічний / словесний опис bubblesortалгоритму.

Тут відбувається процедурна / псевдокодова реалізація

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

Це було легко.

Як це передається OOP ? Ви можете використовувати цей алгоритм для обробки колекцій (самого об'єкта) об'єктів :

Приклад у Javascript (хоч і немає чистого OO-Lingo , але майже без котла та легко зрозуміти)

objects =[{"name":"Peter"}, {"name":"Paul"}, {"name":"Mary"}]

compareObjects=function(x,y){ return x.name>y.name };

sorted = objects.sort(compareObjects)

console.log(sorted)

У нас є: а) колекція objects; б) метод, спільний для цієї колекції, sortякий містить / абстрагує алгоритм сортування та в) наші об'єкти Петро , Павло та Марія . Специфікацію для сортування можна знайти тут .

Яке співвідношення між алгоритмами та OOP? Це дві незалежні теми?

З сказаного, має бути зрозуміло, відповідь повинна бути: так, вони незалежні.

Як OOP може допомогти алгоритмам? Або в якому напрямку це може вплинути?

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

Чи є якісь проблеми, які тільки може бути представлений і вирішений OOP?

Я не можу придумати одного (але це не означає, що це неможливо). Але якщо ви дивитесь навпаки: OOP корисний, якщо ви хочете моделювати деякі проблеми та вирішити ith за допомогою відповідного алгоритму. Скажімо , у вас є запис friendsви могли моделювати їх як objectsз , propertiesі якщо ви хочете listз friends відсортовані в будь-якому випадку, ви могли б використовувати приклад-Наведений вище код , щоб зробити саме це.

Чому підручник алгоритмів більше орієнтований на процедури?

Як сказав: це більш природно , оскільки процедурний є характер алгоритмів.

у вас проблема.

Модель бізнес-домену описує вашу проблему, і поняття з проблемної області, з якою ви збираєтеся мати справу.

Алгоритми описують концептуально спосіб вирішення своїх проблем; як буде виглядати ваша реалізація; і як ви вирішите свою проблему після того, як ви перевели її на терміни "Інформатика".

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

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

Алгоритми = розповісти історію " Як " (тобто як вчасно маніпулювати вхідними даними, використовуючи структури даних для отримання бажаних результатів)

OOP = " Методологія ", що сприяє OO-мовам для написання програм (= алгоритми + структури даних), що забезпечує безпеку пам'яті та абстрагування

OOP - лише парадигма реалізації алгоритмів.

Гарна аналогія : фільми

Ви можете записувати сцени, використовуючи каскадера чи ні. Екран (алгоритм) не змінюється. Люди не повинні бачити різниці в кінцевому результаті.

EDIT: ви можете випробувати якісний MOOC: https://www.coursera.org/course/algs4partI, який перемежовує обговорювані теми (особливо підхід OOP) та дає суть того, що ви тут запитуєте.

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

http://www.stlport.org/resources/StepanovUSA.html

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

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

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

Степанов висловив свою бібліотеку алгоритмів не з Об'єктами, а з Загальними ітераторами .

Алгоритми описують, що повинен робити комп’ютер. Структура описує, як алгоритм викладений [у вихідному коді]. OOP - це стиль програмування, який використовує певні "об'єктно-орієнтовані" структури.

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

У реальному коді життя ви будете використовувати обидві сторони. Ви не можете вирішити комп'ютерні проблеми без алгоритмів, за визначенням, і вам буде складно написати хороші алгоритми без структури (OOP чи інше).

Як приклад, де вони розмиваються, візьміть Динамічне програмування. У книзі алгоритмів ви б описали, як взяти однорідний набір даних у масиві та використовувати Динамічне програмування для досягнення рішення. У книзі OOP ви можете натрапити на таку структуру, як Visitor, що є способом створення довільних алгоритмів для безлічі різнорідних об'єктів. Приклад книги DP можна розглядати як дуже простий відвідувач, що працює над об'єктами в загальному порядку "знизу вгору". Візерунок відвідувачів можна розглядати як скелет проблеми ДП, але не вистачає м'яса та картоплі. Насправді вам часто знадобляться обидва разом: ви використовуєте шаблон Visitor для боротьби з неоднорідністю у вашому наборі даних (DP поганий у цьому), а ви використовуєте DP у структурі Visitor для організації свого алгоритму для мінімізації часу виконання (Visitor не '

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

Чи є якісь проблеми, які може бути представлений і вирішений тільки ООП?

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

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

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

Я не бачу, щоб OOP зник у найближчому майбутньому через те, як думають дизайнери алгоритмів. На сьогодні звичайною схемою є те, що хтось розробляє алгоритм, який не використовує OOP. Спільнота OOP розуміє, що алгоритм насправді не відповідає структурі OOP, і насправді не потрібно, тому вони загортають весь алгоритм у структуру OOP і починають його використовувати. Розглянемо boost::shared_ptr. Алгоритми підрахунку посилань, які shared_ptrзнаходяться всередині , не дуже сприятливі для ООП. Однак модель не набула популярності, поки не shared_ptrстворили навколо неї обгортку OOP, яка розкрила можливості алгоритмів у структурованому форматі OOP. Зараз він настільки популярний, що перетворив його на останню специфікацію для C ++, C ++ 11.

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

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

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

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

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

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

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

Реалізуючи алгоритми в ООП, можна зробити ці менші кроки взаємозамінними.

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

What is the relation between algorithms and OOP? Are they two independent topics?

Алгоритми - це про те, як вирішити проблему (Як генерувати вихід із заданого вводу), OOP - про те, як сформулювати або виразити наше рішення (кроки алгоритму).

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

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

Щоб приховати деталі swapта пов'язати їх із Aсинтаксисом та функцією OOP, OO робить алгоритм наближеним до нашої природної мови та розуміння.

Are there some problems which can only be presented and solved by OOP?

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

How OOP can help algorithms? Or in which direction it can affect it?

Це може допомогти легше або зрозуміліше сформулювати або сформулювати алгоритм. Це може приховати деталі та надати широку картину рішення.

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

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