ООП выполняет обещание повторного использования кода? Какие альтернативы для достижения повторного использования кода?

https://softwareengineering.stackexchange.com/questions/7618

16-10-2019
|

Вопрос

Возможно, самым большим обещанием использования объектно-ориентированной парадигмы является повторное использование кода. Некоторые споры, что это было достигнуто. Почему это (не) было достигнуто?

Повторное использование кода как ООП определяет его, делает проекты более продуктивными?

Или более управляемо? Или легче поддерживать? Или с большим качеством?

Вероятно, мы все согласны с тем, что повторное использование кода - это хорошо, но есть несколько способов достижения этой цели. Вопрос о методе повторного использования кода, предлагаемом ООП. Это было хорошо? Есть ли лучшие методы для достижения повторного использования кода чем объектная ориентация, подклассия, полиморфизм и т. Д.? Какие способы лучше? Почему?

Расскажите нам свой опыт работы с ООП или другими парадигмами повторного использования.

Решение

Повторное использование кода - довольно хорошая идея. Не очень хороший.

У меня есть перспектива примерно из 30 лет разработки программного обеспечения, пытаясь «повторно использовать».

Я начал исследовать «повторное использование кода» как тему исследования еще в 80 -х годах, обнаружив, что повторно использовал дизайн одной ОС, которую я построил в начале 70 -х годов, для другой ОС, которую я построил в конце 70 -х годов.

Хорошей частью повторного использования кода является возможность иногда повторно использовать честный до богослужащего ранее существовавший код. Но мир полный кода; Как найти то, что вы хотите? Вот что я называю Повторно используйте проклятие:

Я Санта -Клаус (OK OK Open Source), и у меня есть мешок с 1 миллиардами программных компонентов. Вы можете иметь любой из них.

Удачи в выбор.

Чтобы хорошо решить проблему повторного использования:

Reaser должен каким -то образом указать, что ему нужно (функции, производительность, целевой язык, предположения окружающей среды, ...)
Должна быть библиотека «многоразового» кода, которая по -разному индексирована по этим потенциальным критериям
Некоторый механизм должен существовать, чтобы выбрать элементы кандидатов (на миллиардах элементов вы не можете смотреть на них всех лично)
Должен быть способ характерного характера, насколько далеко от спецификации выбранные кандидаты
Некоторый регулярный процесс должен существовать, чтобы позволить reuser модифицировать выбранного многократного кода (здесь является наибольшим вкладом OOP: вы можете редактировать существующий компонент/объект, переопределив его слоты. OOP не оказывает никакой другой помощи).
Все это должно быть явно дешевле, чем просто перекодировать

В основном то, что было обнаружено за эти годы, так это то, что для того, чтобы код был повторно используемым, он должен быть разработан для этой цели или содержит слишком много неявных предположений. Самые успешные библиотеки повторного использования кода на самом деле были довольно маленькими. Возможно, библиотеки и структуры являются «многоразовым» кодом, и они чрезвычайно успешны; Java и C# преуспевают не потому, что они довольно хорошие компьютерные языки, а скорее потому, что они имеют огромные хорошо разработанные, реализованные и документированные библиотеки. Но люди не смотрят на исходный код в библиотеках; Они просто называют хорошо документированный API (предназначенный для использования).

Какое повторное использование кода не было сделано (ООП ни другое) - это улучшение порядка в нашей способности кодировать системы.

Я думаю, что ключ -недостаток в том, что Любой вид повторного использования кода в основном ограничен, потому что код имеет слишком много встроенных предположений. Анкет Если вы делаете код крошечным, вы минимизируете предположения, но тогда стоимость строительства с нуля не очень большая, а повышение повторного использования не эффективно. Если вы сделаете кусочки кода огромными, они почти бесполезны в новом контексте. Как и Гулливер, они привязаны к пляжу на миллион крошечных струн, и вы просто не можете позволить себе разрезать их все.

Над чем мы должны работать Повторное использование знаний для построения кода. Анкет Если мы сможем это сделать, то мы можем применить эти знания для построения кода, который нам нужен, обрабатывая текущий набор допущений.

Для этого все еще нужна та же возможность спецификации для характеристики компонентов программного обеспечения (вам все еще нужно сказать, что вы хотите!). Но затем вы применяете эти «строительные» знания к спецификациям к генерировать Код, который вы хотите.

Как сообщество, мы еще не очень хороши в этом. Но люди делают это все время; Почему мы не можем его автоматизировать? Есть много исследований, и это показывает, что это можно сделать во многих обстоятельствах.

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

Компиляторы уже делают это:-}, и они действительно хороши в классе проблем, которые они решают.

Модели UML с генерацией кода являются одной из попыток сделать это. Не очень хорошая попытка; В значительной степени то, что говорят в большинстве моделей UML, «у меня есть данные, которые выглядят так». Довольно сложно генерировать реальную программу, если функциональность не исключена.

Я пытаюсь построить Практические системы преобразования программ, инструмент под названием DMS. Анкет Был довольно хорошо отвлечен, применяя преобразования программ не столько абстрактных спецификаций для создания кода, а к устаревшему коду для его очистки. (Это та же проблема в реферате!). (Чтобы создать такие инструменты, занимает много времени; я занимаюсь этим 15 лет, и в то же время вам нужно есть).

Но DMS обладает двумя ключевыми свойствами, которые я описал выше: способность обрабатывать произвольные формальные спецификации и способность захватывать «знания генерации кода» в качестве преобразования и применять их по требованию. И примечательно, что мы создаем в некоторых особых случаях, некоторые довольно интересные коды из спецификаций; DMS в значительной степени построен с использованием себя для генерации своей реализации. Это достигло нам, по крайней мере, некоторых обещаний (знаний) повторного использования: чрезвычайно значительный рост производительности. У меня есть команда из 7 технических людей; Мы написали, вероятно, 1-2 MSLOC «спецификации» для DMS, но имеем около 10 мслака сгенерированного кода.

Резюме: Повторное использование знаний поколения это победа, а не Повторное использование кода.

Другие советы

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

Этот тип повторного использования кода также делает код более управляемым, потому что изменение этого одноразового блока изменяет все места, которые он называется. Я бы сказал, что этот результат также повысил качество и читаемость.

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

Из Викпедии:

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

Да и нет

Повторное использование кода является общепринятым термином для многих различных действий.

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

Я бы опубликовал длинный ответ, но почему? Уди Дахан объясняет это намного лучше, чем я.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

Вот начало поста:

Эта отрасль предварительно занята повторным использованием.

Есть это убеждение, что если мы только что повторно используем больше кода, все будет лучше.

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

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

Я мог бы также позволить вам в секрете грязного светильника:

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

Я согласен с Крисом, функциональное программирование - хороший способ повторного использования кода.

Многие программы имеют повторяющиеся структуры кода. Для этого некоторые шаблоны проектирования используются в мире ООП, но это может быть достигнуто рекурсивные функции а также соответствие рисунка в языках функционального программирования. Подробнее об этом см. Первую главу в Функциональное программирование реального мира.

Я думаю, что глубокое наследство в ООП может вводить в заблуждение во многих случаях. У вас есть класс, и многие из тесно связанных методов реализованы в разных файлах. В качестве Джо Армстронг сказал о ООП:

Проблема с объектно-ориентированными языками заключается в том, что у них есть вся эта неявная среда, которую они несут с собой. Вы хотели банан, но у вас была горилла, держащая банан и все джунгли.

Функции высокого порядка также очень полезны, когда дело доходит до повторного использования кода, например, map а также foldr Это основа для Google Уменьшение карты.

Асинхронное сообщение прохождение также является хорошим способом организовать сложное программное обеспечение, и некоторые компьютерные ученые утверждают, что объекты должны были общаться с друг другу асинхронным, как в Скажи, не спрашивай Принцип ООП. Узнайте больше об этом в Программирование объектно -ориентированного: неправильный путь? мы Джо Армстронг цитируется:

Я начал задаваться вопросом о том, что было объектно -ориентированное программирование, и я думал, что Эрланг не был ориентирован на объект, это был функциональный язык программирования. Затем, мой руководитель диссертации сказал: «Но вы не правы, Эрланг чрезвычайно ориентирован на объект». Он сказал, что объектно -ориентированные языки не ориентированы на объект. Я мог бы подумать, хотя я не совсем уверен, верю ли я в это или нет, но Эрланг может быть единственным объектно -ориентированным языком, потому что 3 принципа объектно -ориентированного программирования - это то, что он основан на передача сообщения, что у вас есть изоляция между объектами и иметь полиморфизм.

Асинхронное сообщение, проходящее как в системах, управляемых событиями, и в Erlang также является очень хорошим способом отделки систем и Слабая связь важно в сложных системах. Благодаря достаточно разъединенной системе вы можете развивать систему во время ее работы, возможно, на разных узлах. Unibet сделал отличную презентацию об этом: Доменная архитектура, управляемая событиями

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

Скромная труба Unix сделала больше для повторного использования кода, чем все, что пришло и ушло. Объекты оказались интуитивно понятным способом структурирования кода, когда они пришли, и позже люди начали затягивать все и все. В целом объекты предназначены для инкапсуляции, а не для повторного использования кода, повторное использование кода требует чего -то большего, и иерархия наследования класса является плохой заменой, каким должен быть механизм повторного использования кода.

ООП не особенный; Вы можете сделать многоразовый код с ООП или без него. Чистые функции особенно используются повторно: Например, java.lang.math.sqrt(double) берет номер и дает номер. Нет ООП, но определенно более повторно используется, чем большинство кодов.

Из функционального просмотра программирования ООП в основном о управлении состоянием.

В функциональном программировании вы можете легко иметь сотни полезных функций для списков: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/data-list.html.

У вас есть сотни методов в классе списка? Публичные методы считаются интерфейсом для внутреннего состояния, которое вы хотите сохранить маленьким.

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

Для меня, да, но не все время, и это могло быть сделано иным образом.

Большую часть времени создавая абстрактный базовый класс и создавая конкретные реализации этого класса.

Также многие рамки используют наследование для предоставления повторного использования кода (Delphi, Java, .net - это лишь некоторые, которые сразу же напоминают).

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

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

ООП слишком открыт для эффективного повторного использования.

Есть слишком много способов повторного использования. Каждый публичный класс спрашивает: "Сделай новый экземпляр меня!", каждый публичный метод говорит: "позвони мне!", каждый защищенный метод дает: "Переопределите меня!" - и все эти способы повторного использования другой, У них разные параметры, они появляются в разных контекстах, все имеют свои различные правила, как вызовать/расширить/переопределить его.

API Лучше, это строгая подмножество ООП (или неплы) точек, но в реальной жизни API переполняются и навсегда растут, все еще слишком много точек соединения. Кроме того, хороший API может облегчить жизнь, это лучший способ обеспечить интерфейс для ООП.

Парадигма DataDlow Предоставляет строгий интерфейс для компонентов, у них есть порты следующих типов:

потребители (входные данные) и
производители (выходы).

Зависит от домена, есть некоторые типы пакетов, поэтому потребители и производители могут быть подключены к нему, они имеют одинаковые (или совместимые) порты. Самая красивая часть этого, которую он может сделать визуально, потому что нет параметров или настройки на подключениях, они действительно просто соединяют потребителя и производителя.

Мне было немного неясно, вы можете взглянуть на Тег "Dataflow" на StackoverFlow, или же Википедия "Программирование данных" или Википедия "Программирование на основе потока".

(Кроме того, я написал систему потока данных, в C ++. Таким образом, OOP и DF не являются врагами, DF является организационным способом более высокого уровня.)

В Commonlisp есть много средств для достижения повторного использования:

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

Если вы попытаетесь сравнить опыт Commonlisp с другими языками, вы увидите, что основная функция, которая облегчает повторное использование кода, - это наличие оба объектно-ориентированные и функциональные абстракции. Они более комплементарны, чем альтернатива: без одного из них вы вынуждены переопределить недостающие функции неуклюжими. См., Например, классы функций, используемые в качестве закрытия и сопоставления шаблонов для получения невозможности отправки метода.

Там действительно нет такой вещи, как «повторное использование», как люди это описывают. Повторное использование случайный собственность чего -либо. Трудно запланировать это. Большинство людей имеют в виду, когда говорят о «повторном использовании», - это «использование». Это гораздо менее привлекательный и захватывающий термин. Когда вы используете библиотеку, вы используете ее для того, для чего она предназначена, обычно. Ты нет Повторно используя его, если вы не делаете что -то действительно безумное с этим.

В этом смысле повторное использование в реальном мире-это переосмысление вещей. Я могу повторно использовать эти места здесь и изменить их, чтобы сформировать ... кровать! Не очень удобная кровать, но я могу это сделать. Это не их основное использование. Я повторно использую их за пределами их первоначальной области применимости. [...] Завтра я вернусь в Великобританию. Я буду нет повторно используйте самолет. Я просто буду использовать его для цели, для которой она была предназначена, в этом нет ничего особенного или захватывающего.

- Кевлин Хенни

Я собираюсь рисковать насмешками и признаться, я использовал ООП только недавно. Это не приходит ко мне автоматически. Большая часть моего опыта включает в себя реляционные базы данных, поэтому я думаю, что в таблицах и объединениях. Существуют утверждения о том, что лучше научиться с самого начала, что позволяет избежать необходимости переосмыслить ваше мышление, когда дело доходит до программирования. У меня нет этой роскоши и отказываться от того, чтобы отказаться от своей карьеры по теории башни из слоновой кости. Как и все остальное, я выясню.

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

Повторное использование кода требует готовности не повторять код, понимание того, как его достичь, предварительное планирование. Должны ли вы избегать повторного использования кода, когда вы решили, что у вас есть случай, когда он просто не стоит? И ни один язык не настолько строго, что он принесет ошибку, когда думает, что вы должны унаследовать код из другого класса. В лучшем случае они предоставляют среду, способствующую ее реализации.

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

Я видел достаточно процедурного кода, чтобы знать, что он может быть где угодно, а иногда и везде.

ООП дает вам более способы повторного использования кода. Это все.

Горизонтальное повторное использование: аспекты, черты, трансплантаты

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

Аспект, ориентированное на программирование

Я считаю AOP отсутствующим полуоружным ООП. AOP на самом деле не так известно, но он попал в производственный код.

Я попробую это объяснить в простых терминах: представьте, что вы можете вводить и фильтровать функциональность со специальной структурой, называемой аспектом, эти аспекты имеют «методы», которые определяют, что и как будет затронуто через отражение, но во время компиляции этот процесс называется ткачество.

Примером может быть аспект, который рассказывает «для всех методов определенных классов, которые начинаются с GET, программа вы записываете в файл журнала, которые были получены, и время, которое оно было получено».

Посмотрите эти два разговора, если вы хотите лучше понять AOP:

Черты и трансплантаты

Черты являются еще одной конструкцией для определения многоразового кода, который дополняет ООП, они похожи на микшины, но чище.

Вместо того, чтобы объяснять их, есть отличный PHP RFC, который объясняет оба. Анкет Черты приходят к PHP, кстати, они уже готовы к туловище.

В итоге

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

OOP предоставляет набор полезных инструментов, которые позволяют вам писать код, который можно использовать в большем количестве мест, чем вы могли бы без этих инструментов. Если вы напишете PrintIt функция, которая принимает любой старый объект и вызовы .toString() На нем вы повторно используете этот код, как только вы позвоните ему с более чем одним типом объекта. С этими инструментами, Каждая строка кода делает больше.

Функциональное программирование сейчас очень жарко среди хипстеров. Это дает вам целый отдельный Набор инструментов, чтобы каждая строка кода делала больше. Это, вероятно, не лучше или работает, но предоставляет еще один инструмент в наборе инструментов.

(Была безумная идея для целого дополнительного уровня объектно-ориентированного повторного использования: идея заключалась в том, что мы можем определить один Customer класс и используйте его в каждом приложении, которое мы написали. Тогда приложения были бы немного клеем здесь и там. Это не сработало. Но это не значит, что ОО не удалось, или даже это повторное использование не удалось. Основные типы повторного использования кода в приложениях позволили писать приложения, которые сделали больше, и писать их быстрее.)

Читая приведенные выше посты, несколько замечаний:

Многие думают, что повторное использование кода в ООП подразумевает наследование. Я не согласен. Интерфейсы и контракты являются ядром повторного использования кода в системах ООП. ООП - это серый коробка попытка создания компонентной технологии.
Разница между специфическим доменом и общими «структурами» как предметом повторного использования считает меня слишком абстрактным. На мой взгляд, на вещи, компонент (краткий, минимальный и многократный контракт на интерфейс и реализация) может быть выполнена только в том случае, если проблема, с которой он решает, хорошо понята. Специфический компонент, который позволяет экспертам, не доменам выполнять свою работу с меньшими знаниями о домене, является (повторным) полезным компонентом. Пользователи должны понимать интерфейс, меньше, чем тонкости проблемного домена.
Уровни повторного использования часто забывают: повторное использование идеи, повторное использование спецификации, повторное использование архитектуры/дизайна, повторное использование интерфейса, повторное использование тестирования. Повторное использование кода не всегда выгодно. Но это большая экономия, часто придерживаться конкретной архитектуры, чтобы справиться с новым, подобным продуктом.
Модели дизайна ООП (Gamma et. Al) в моих глазах подробно описывались на методы тактической реализации, а не имеют смысла в контексте повторного использования кода в более широком масштабе. Они помогают написать приложение с элементами ООП, но я бы не стал их решением решения «повторное использование кода» за пределами одного приложения.
Может быть, это несправедливо: 20 лет опыта C/C ++/C# и 6 -месячное функциональное программирование (F#). Одним из основных элементов включения повторного использования является: люди должны легко найти «интерфейс», изучать его, понять, а затем использовать его. Чистое функциональное программирование не позволяет мне видеть структуру, кандидатов на повторное использование или где все начинается и где все заканчивается. Такой хвалящий «синтаксический сахар» часто - соль в моих глазах, что мешает мне легко увидеть, что происходит. Таким образом, я бы менее вероятно попытался повторно использовать функциональный (что это-куча функций?), Которые могут иметь скрытые побочные эффекты, которые я даже не вижу (ленивая оценка, монады, ...). Не поймите меня неправильно, функциональное программирование имеет очень крутые стороны, но все сильные стороны провозглашены, я вижу с хорошей мерой сомнения. Мне очень любопытно, что приносит постфункциональное будущее, и надеюсь увидеть его до того, как я уйдет в отставку;)
Спецификация, проектирование, реализация связаны, но нелегко обновлять взгляды на «то же самое». Гораздо больше жизненно важнее для повышения будущей производительности, чем новая парадигма программирования, заключается в том, чтобы сократить разрыв, увеличить (автоматизированные рассуждения, отслеживаемость) взаимные преимущества между этими взглядами. Формализованные языки спецификации, стандартизированные тестовые обозначения (например, TTCN3) и языки программирования, поддерживающие проверку интерфейсов и контракты со спецификациями без литературы комментариев, могут быть тем, что нам нужно больше всего срочно.

Проблема более тонкая ИМХО:

ООП - это Отличный метод структурирования кода с изменчивым состоянием. Анкет Инкапсулируя государство в объекты, императивный код Statefull становится более понятным, потому что, например, если часть состояния выражается как частные поля класса, вы знаете, что По крайней мере, этот конкретный предмет состояния может быть изменен только методами этого класса. (И вы можете легко сломать эту выгоду, злоупотребляя наследством, кстати.) Сейчас этого достаточно, но Вааай лучше чем не иметь даже этого.
Код с изменчивым состоянием по своей сути трудно повторно использовать. Анкет Гораздо сложнее, чем код, используя неизменные структуры данных.

Так ООП само по себе неплохо от POV для создания многоразового кода, но Виды кода, которые записаны с использованием ООП, по своей сути трудно повторно использовать.

Также, функциональное программирование может привести к больше многоразового кода. Анкет Но получить правильные абстракции для написания чистого функционального кода при соблюдении крайнего срока может быть невозможным. И абстракции «половина правой» будут легче выразить стиль ООП. И это не приведет к легче использовать код повторного использования - Более высокий уровень абстракций означает, что понимание кода потребует более высоких авансов от ограниченных когнитивных способностей программистов.

Как практический пример: Игровой код включает в себя много изменяемого состояния, потому что это естественный способ подумать о кодировании игры, если только это не очень головоломка/алгоритмическая, так что он, очевидно, в конечном итоге структурирован с помощью OO. И, конечно, это трудно повторно использовать. Но тот же код, содержащий одинаковые знания, было бы еще сложнее повторно использовать без ООП. Анкет И переписать его в функциональном стиле может потребоваться Полностью изменить способ, которым вы думаете об этом коде, знаниях за ним. Да, в результате Знание за кодом Было бы намного яснее после того, как оо, чтобы переписать, может быть, ... но стоимость может быть огромной и это может быть вид, который также должен быть заплачен людьми, желающими повторно использовать невероятно умный и хорошо абстрактный код, который вы в конечном итоге, Как ни парадоксально, люди не будут повторно использовать код, даже если технически он более используется.

... что приводит к последней тонкости: повторное использование кода - это о Люди | Код Интерфейс, а не только о коде. OOP делает достойную работу по обслуживанию этого интерфейса, потому что он хорошо отображает с тем, сколько людей думают о многих видах кода, написанного в настоящее время. FP может быть лучше для повторного использования кода, но не для Легко повторно используя тот код, который людям действительно нужно писать в наши дни. Это изменится как тот код, который нам нужно написать изменения.

PS, и если кто -то хочет сказать, что «OO не о изменчивом состоянии, вы также можете иметь OO с неизменным состоянием» ... Я называю это «FP с использованием классов в качестве пространств имен». Это здорово, когда это работает для вас, и это избегает некоторых недостатков систем модулей некоторых языков и может привести к более многократному коду. Но это не оо;)

Лицензировано под: CC-BY-SA с атрибуция

Не связан с softwareengineering.stackexchange