Доставлены ли объекты с точки зрения повторного использования кода?

17

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

Casebash
источник
4
Я никогда не слышал, чтобы кто-нибудь говорил это ...
TheLQ
2
@ Я не верю, что на самом деле слышал, как кто-то говорил это, но я прочитал это.
Джордж Мариан
Повторное использование не единственное преимущество ООП.
Никто
2
"Были ли объекты доставлены с точки зрения повторного использования кода?" -> Только если вы поверили продавцам ООП в те времена (это были 60-е годы? Я забыл)
Стивен Эверс
Мой ответ на похожий вопрос: programmers.stackexchange.com/questions/53521/…
Кевин Клайн

Ответы:

18

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

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

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

Джордж Мариан
источник
Ну да. Но помогли ли объектам разработчики библиотек, предоставив им опции, облегчающие повторное использование их библиотек? Я бы сказал , что они есть, и , следовательно , объекты были доставлены усовершенствованную повторного использования.
Жюль
@ Джулс Я тоже люблю спорить только ради обсуждения. Я бы не стал утверждать, что объекты не облегчают проектирование библиотек. Я утверждаю, что правильное использование ваших инструментов приводит к правильным результатам.
Джордж Мариан
7

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

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

Hobbs
источник
Повторное использование кода - это определенно то, к чему нужно стремиться, когда вы можете избежать
потери
1
Повторное использование кода не является самоцелью. Повторное использование это еще одно слово для связи. Таким образом, вы должны подходить к повторному использованию осторожно. Кажется, многие разработчики забывают об этом. Они хотят развязать системы, но оборачиваются и пытаются использовать существующие классы везде.
Энди
5

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

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

Shog9
источник
5

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

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

Вальтер
источник
4
Разные статьи. А из личного опыта сделать объект многократного использования совсем не просто
Casebash
3

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

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

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

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

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

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

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

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

Билл К
источник
2

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

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

Huperniketes
источник
2

да

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

нет

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

По-разному

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

Стивен А. Лоу
источник
1

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

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

Fishtoaster
источник
4
Я согласен, что объекты делают код приятнее, но, к сожалению, такая большая часть моих объектов не может быть использована повторно. Зачастую создание объекта для повторного использования означает упрощение ситуации
Casebash
2
@casebase +1 Однако я бы сказал, что повторное использование объектов означает усложнение ситуации (объекта).
Джордж Мариан
Не все будет многоразовым. Большинство вещей не будет. Однако слабая связь, сокрытие информации и т. Д. Являются необходимыми условиями для повторного использования, и объект способствует этому.
Fishtoaster
2
@ Fishtoaster: вы могли бы также сказать, что движение вашего автомобиля является необходимым условием для начала работы, и наклонная дорога способствует этому. Это технически верно, но вряд ли что-то изменит за пределами крайних случаев: если вам нужно и вы хотите использовать повторно, вы получите, ОО или нет; если вы этого не сделаете, то наличие предпосылок не сделает это случайным.
Shog9
@Г-н. C- Я не уверен, что следую вашей точке зрения. Я просто заявлял, что вещи, которые поддерживает ООП (модульность и т. Д.), Облегчают создание таких вещей, как библиотеки. Существует множество способов сделать код многократно используемым путем разделения задач и т. Д. ООП - это одно, хороший метод разработки - это другое, правильная декомпозиция проблемы - это еще одно.
Fishtoaster
1

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

Gaurav
источник
1

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

programmx10
источник
0

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

vpit3833
источник