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

Ні, не обов’язково.

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

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

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

Щоб відповісти на питання трохи детальніше, є колекція досить хороших інструментів, щоб уникнути повторення: успадкування, ознаки, делегування, функції вищого порядку тощо. З них люди схильні плутати спадщину з ОО в цілому - і Вони також прагнуть трохи зловживати цим, якщо ви запитаєте мене. Можливо, саме звідси походить деякий вигляд "OO sucks": пошук спадщини застряг там, де воно не має природного права бути :)

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

OO - це зручна абстракція для багатьох проблем, але будьте обережні, ажіотаж 80-х - 90-х: він не вирішує магічні основні проблеми нашої торгівлі більше, ніж робить вафлі для вас під час сну.

Я не сподіваюсь, що ВСІ об’єкти будуть повторно використані, але у нас є багато об'єктів, які ми повторно використовуємо у багатьох різних проектах. У нас також є об'єкти, які просто повторно використовуються в одному проекті. Ми часто споживатимемо ті самі бізнес-об’єкти (або об’єкти передачі даних), а також об’єкти бізнес-логіки з додатку для робочого столу Click-Once, веб-програми та додатку для телефону для одного проекту.

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

Деякі програмісти будуть копіювати та вставляти будь-яку мову та стиль.

Дійсно хороші програмісти можуть уникнути більшості копій та вставлення майже будь-якою мовою.

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

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

пс. Я знаю, що у людей будуть проблеми з попереднім пунктом, тому я трохи поясню.

Установці та геттери викликають проблеми з ОО, оскільки вони дозволяють оперувати членами об'єкта (об’єкт повинен маніпулювати його власними членами). Це поширює код, який працює у вашому класі по всіх інших класах, вимагаючи від вас скопіювати функціональність навколо сеттера / геттера . Це стосується і властивостей - лише тому, що Властивості простіші, не роблять їх "хорошими" у будь-яких ситуаціях.

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

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

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

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

Так

OOP надає більше способів повторного використання коду

Ні

немає срібної кулі

Це залежить

на те, що ви вклали в це, і що ви очікували взамін!

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

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

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

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

Якщо це досі вони виконали обіцянку повторного використання коду? Так, якщо програми, написані на увазі OOP, розумно застосовують шаблони дизайну. Інакше в основному немає. Але, дивлячись на популярність широкомасштабних нетривіальних програм, які Adobe-системи, Google тощо подібні пишуть на C ++ або Java чи інших мовах OOP, я б сказав, що OOP має пройти довгий шлях до його припинення. Цей час буде набагато зручніше поставити це питання і може допомогти у створенні наземних робіт для нової парадигми.