Чи стає OOP легше чи складніше? [зачинено]

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

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);

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

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

Примітка. Я не проти найкращих практик, що полегшують співпрацю, тестування та інтеграцію

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

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

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

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

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

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

Ні, він стає все більш переробленим. І ви маєте рацію - в чаті SO C ++ ми часто жартуємо про AbstractSingletonFactoryProxyBeanBridgeAdapterManagers, який ми бачимо в коді Java.

Але хороший код не виявляє цю властивість. У хорошому коді ви все ще можете сказати

std::stack<int> s;
s.push(5);
s.pop();

Я б сказав, що проблеми зі «складністю», про які ви згадуєте, не мають нічого спільного з ООП. Це має більше спільного з відокремленням проблем.

Багато років тому я працював над системою, де доменний клас відповідав за завантаження з бази даних, наприклад

var userId = Request.QueryString["UserID"].ToInt();
var user = new User(userId);
user.Name = ...;
...
user.Save();

Це дуже чіткий код. Немає проблем у розумінні цього. Однак проблема полягає в тестуванні коду. А саме, як би я тестував Userклас, не завантажуючи його з бази даних? І як би я перевірив цей код обробки веб-запитів, не маючи доступу до бази даних? Це просто неможливо.

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

Тож якщо ми повернемося до прикладу, який ви пишете, що б ви зробили з запасом після його створення? Збережіть його в базі даних

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);
this.StockRepository.Add(stock);

Там, зробили! Немає руху в прогресуванні ООП, що говорить про те, що це повинно бути важче. На жаль, якщо ви вибрали для використання коду доступу до даних АБО Map Map, ви можете зіткнутися з проблемою, що картографічний оператор OR АБО встановлює обмеження щодо того, як можна записати вашу систему. Але це вже інша справа.

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

Ні. Наші проблеми насправді не змінилися; панель прийнятного коду піднята.

Для досягнення зазначеного вам може знадобитися створити кілька класів (наприклад, конспект, фабрика, DAO тощо) та впровадити декілька інтерфейсів

Вам не потрібно цього робити. Але якщо ви цього не зробите, проблеми виникають; проблеми, які завжди були там. Однак програмісти мають достатньо досвіду для виявлення цих проблем та створення механізмів їх полегшення (якщо потрібно). Ми дізнаємось більше про них і підходимо до кращих рішень (див., Наприклад, погляд програмістів на синглтон).

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

Приклади "введення в ОО" набагато простіші, ніж у реальному світі. Вам потрібен лише один клас, щоб досягти сказаного. Проблема в тому, що він не робить багато. Деякі зразки дизайну намагаються наблизитися (наприклад, ActiveRecord.) Але в кінцевому підсумку будь-який приклад, який не є тривіальним, матиме більше одного класу; що це нормально.

Мови програмування, які сьогодні використовують OO, намагаються задовольнити складні вимоги та умови, які постійно змінюються. OO дозволяє своїм приймачам приховувати різноманітні рівні складності (серед інших особливостей), щоб кодування стало більш зрозумілим і легшим у побудові та розумінні. Однак ця функція не завжди є поза рамкою. У вашому прикладі, OO дозволило вам приховати від мене деякі деталі, надавши метод управління елементами в колекції і, можливо, навіть зберегти його за допомогою методу "AddItem". Витрати зусиль на приховування складності можуть призвести до простоти у використанні та багаторазового використання, що спрощує життя. Наприклад, багато реалізацій ORM дозволяють спілкуватися з базами даних, не вимагаючи від програміста запису даних про SQL. Це дійсно потужно і робить його простішим для розробника.

Шаблони, на які ви посилаєтесь, - це саме те. Вони повинні полегшити ваше життя. Але від вас залежить їх прийняття та коригування. Те, що потрібно більше працювати, це лише тому, що ви отримуєте більше переваг. Це як платити більше за Ferrari. Якщо ви хочете, щоб ви доплачували за них. Отже, якщо ви вирішили створити масштабоване рішення N-Tier, яке можна запустити на декількох серверах і різних базах даних із зворотнього боку, для цього є вартість. Якщо ваша заявка не потребує такої складності, ігноруйте зайві фрагменти та поверніться до найпростішого рішення, яке покриває ваші потреби (KISS & YAGNI).

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

Коротка відповідь : Так, тому що ви вирішуєте більш складні проблеми.

Довгий відповідь (сильно упереджений) : Для мене шаблони дизайну зазвичай вказують на те, що деякі парадигми мають проблеми в даній області. Шаблони OOP стосуються проблем OOP (на нижньому рівні шаблони Java стосуються проблем Java), моделі FP - проблеми FP тощо.

Під час програмування у вас можуть бути різні пріоритети. Ви можете мати правильну програму, ви можете мати короткий час на ринок, найшвидшу програму, довгострокову ремонтоздатність або миттєву ремонтопридатність новим наймом. Залежно від густоти, в якій ви перебуваєте, у вас буде дуже різне - якщо ви програмуєте контролер електростанції, ви хочете робити це вперше, а не виправляти помилки ("Чи відбувається занепад кожного разу, коли ви натискаєте Ctrl+Alt+Del?"). Якщо ви перебуваєте в HPC, логіка може бути відносно простою, але ви хочете виконати її якомога швидше тощо. Крім того, деякі парадигми краще відповідають певним проблемам (скажімо, AI та логічне програмування, дані та реляційні бази даних).

OOP до певної міри "занадто хороший" у простих випадках, і це історія "моделювання реального живого". Наприклад , в першій книзі про ООП я прочитав там були класи Person, Employeeі Managerз is-aвідношенням. Поки що добре, але що робити, якщо працівника підвищують до менеджера?

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

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

PPS. Так - використовуйте шаблони дизайну - вони роблять програмування OOP в кінцевому рахунку більш простим.

PPPS. Я використовував OOP як синонім імперативного програмування OOP.

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

Ранні книги OOP (особливо ранні книги Java) представляли абсурдно спрощений погляд на програмування додатків. Приклади "Дебетування банківського рахунку з програмою Java на 10 ліній" завжди були особливо прикро, оскільки я бачив приклади реального життя цього простого завдання, що працює на 6000 рядків коду COBOL (і спроба заміни Java працює до 3500 рядків до того, як вона була відмовлена як нездійсненне!).

На щастя, книги OO тепер, як правило, визнають складнощі реального життя та надають корисні приклади того, як з ними боротися.

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