Я часто слышал, что объекты не были переданы с точки зрения повторного использования кода. Вы согласны? Если вы верите, что нет, почему бы и нет?

Нет, не обязательно

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

Хорошо спроектированные библиотеки обещают повторное использование кода, а не объекты как таковые.

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

Чтобы ответить на этот вопрос чуть более прямо, есть набор довольно хороших инструментов, позволяющих избежать повторения: наследование, черты, делегирование, функции высшего порядка и т. Д. Из них люди склонны путать наследование с ОО в целом - и они также склонны немного злоупотреблять этим, если вы спросите меня. Может быть, именно отсюда и возникает какая-то атмосфера "ОО сосет": найти наследство, застрявшее там, где у него нет естественного права быть :)

Нет, «объекты» не сделали повторное использование кода более простым и распространенным. Те же проблемы, которые препятствуют повторному использованию кода в модульной программе (разработка, тестирование и документирование API общего назначения требует значительно больших предварительных усилий, чем написание одноразовой процедуры, и мастером на все руки может быть мастер ничего - логика, предназначенная для повторного использования, не может быть хорошо оптимизирована для целей, к которым она фактически применяется) применима к ОО-программам, с дополнительной опасением, что плохо разработанная объектная модель может затруднить повторное использование иным образом повторно используемых код.

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

Я не ожидаю повторного использования ВСЕХ объектов, но у нас есть много объектов, которые мы повторно используем во многих различных проектах. У нас также есть объекты, которые просто повторно используются в одном проекте. Мы часто будем использовать одни и те же бизнес-объекты (или объекты передачи данных), а также объекты бизнес-логики из настольного приложения Click-Once, веб-приложения и телефонного приложения для одного и того же проекта.

Где вы слышали, что ОО не доставляет при повторном использовании? И в чем была причина? Возможно, дизайн их объектов заставил их в этой ситуации ...

Некоторые программисты будут копировать и вставлять на любом языке и в любом стиле.

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

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

Также в тех случаях, когда мы используем не-оо-паттерны или оо-анти-паттеры, такие как сеттеры / геттеры, операторы switch, анонимные внутренние классы, огромные функции и т. П., Как я видел, повторное использование кода идет вниз, а шаблон - повышается ... значительно.

пс. Я знаю, что у людей будут проблемы с предыдущим абзацем, поэтому я объясню немного.

Сеттеры и геттеры вызывают проблемы OO, потому что они позволяют вам работать с членами объекта (объект должен манипулировать его собственными членами). Это распределяет код, который работает с вашим классом, по всем другим классам, требуя от вас скопировать функциональность вокруг сеттера / геттера. , Это относится и к свойствам - просто потому, что свойства проще, они не делают их «хорошими» во всех ситуациях.

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

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

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

Как только команды разработчиков придают большее значение повторному использованию тестируемого кода, чем сохраняя все детали в своей голове, вы увидите гораздо более детализированные объекты и методы и, следовательно, больше повторного использования кода.

да

ООП дает вам больше способов повторно использовать код

нет

нет серебряной пули

По-разному

на то, что вы положили в него, и что вы ожидали взамен!

Да. Хорошее объектно-ориентированное программирование способствует разделению проблем, слабой связи, высокой сплоченности и сокрытию информации. Эти вещи очень важны для повторного использования кода.

Я бы сказал, что основным преимуществом ООП является модульность и модифицируемость, а не повторное использование, но это другой вопрос.

Объекты позволяют повторно использовать код, но как таковые - не самая лучшая техника для этого. Я думаю, что повторное использование кода продвигается с помощью методов, связанных с объектами, таких как наследование, полиморфизм, перегрузка и шаблоны.

Да, это так, способность расширять (наследовать) от очистного класса суперкласса способствует повторному использованию кода, я не уверен, как кто-либо может утверждать иначе. Вы можете просто расширить класс и переопределить один метод, используя остальные из суперкласса, если это не помогает в повторном использовании кода, тогда я не знаю, что

Если они выполнили свое обещание повторного использования кода до сих пор? Да, если программы, написанные с учетом ООП, разумно применяют шаблоны проектирования. Иначе в основном нет. Но, глядя на популярность крупномасштабных нетривиальных программ, которые системы Adobe, Google и тому подобное пишут на C ++, Java или других языках ООП, я бы сказал, что ООП еще предстоит пройти долгий путь, прежде чем он будет прекращен. Это время будет гораздо более подходящим для того, чтобы задать этот вопрос, и может помочь в подготовке основ новой парадигмы.