Выполняет ли ООП обещание повторного использования кода? Какие существуют альтернативы для достижения повторного использования кода?
Повторное использование кода — неплохая идея. Не великий.
У меня есть точка зрения, основанная примерно на 30-летнем опыте разработки программного обеспечения, когда я пытаюсь «повторно использовать».
Я начал исследовать «повторное использование кода» как тему исследования еще в 80-х, после того как обнаружил, что повторно использовал дизайн одной ОС, которую я создал в начале 70-х, для другой ОС, которую я создал в конце 70-х.
Хорошей частью повторного использования кода является возможность иногда повторно использовать ранее существовавший код. Но мир полон кода; как найти то, что вы хотите? Вот что я называю проклятием повторного использования:
Я Санта-Клаус (хорошо, с открытым исходным кодом), и у меня есть мешок с 1 миллиардом программных компонентов. Вы можете иметь любой из них.
Удачи в выборе.
Чтобы хорошо решить проблему повторного использования:
- повторный пользователь должен каким-то образом указать, что ему нужно (функционально, производительность, целевой язык, предположения среды, ...)
- должна быть библиотека «повторно используемого» кода, который был проиндексирован различными способами по этим потенциальным критериям
- должен существовать какой-то механизм для выбора элементов-кандидатов (при миллиарде элементов вы не можете просмотреть их все лично)
- должен быть способ определить, насколько далеки от спецификации выбранные кандидаты.
- должен существовать какой-то регулярный процесс, позволяющий повторному пользователю изменять выбранный повторно используемый код. (вот самый большой вклад ООП: вы можете редактировать существующий компонент/объект, переопределяя его слоты. ООП не предоставляет никакой другой помощи).
- все это явно должно быть дешевле, чем просто его перекодировать
В основном за эти годы было обнаружено, что для того, чтобы код можно было использовать повторно, он должен быть разработан для этой цели или содержать слишком много неявных предположений. Самые успешные библиотеки повторного использования кода на самом деле были довольно маленькими. Возможно, библиотеки и фреймворки представляют собой «повторно используемый» код, и они чрезвычайно успешны; Java и C# преуспели не потому, что они довольно хорошие компьютерные языки, а скорее потому, что они имеют огромные хорошо спроектированные, реализованные и задокументированные библиотеки. Но люди не смотрят исходный код в библиотеках; они просто вызывают хорошо документированный API (предназначенный для общего использования).
Чего повторное использование кода не дало (в том числе ООП), так это улучшения нашей способности программировать системы на несколько порядков.
Я думаю, что ключевой недостаток заключается в том, что любое повторное использование кода фундаментально ограничено, потому что код имеет слишком много встроенных предположений. прибыль от повторного использования неэффективна. Если вы сделаете куски кода огромными, они будут практически бесполезны в новом контексте. Как и Гулливер, они привязаны к пляжу миллионом крошечных ниточек, и вы просто не можете позволить себе перерезать их все.
Мы должны работать над повторным использованием знаний для создания кода. Если мы сможем это сделать, то сможем применить эти знания для создания нужного нам кода, обрабатывая текущий набор предположений.
Для этого по-прежнему нужны те же возможности спецификации для характеристики программных компонентов (вы все равно должны сказать, что вы хотите!). Но затем вы применяете эти «строительные» знания к спецификациям, чтобы сгенерировать код, который вам нужен.
Как сообщество, мы еще не очень хороши в этом. Но люди делают это все время; почему мы не можем это автоматизировать? Существует множество исследований, и они показывают, что это можно сделать во многих обстоятельствах.
Одним из ключевых механизмов, необходимых для этого, являются механические инструменты для принятия «описаний компонентов» (это всего лишь формальные документы, которые можно анализировать как языки программирования) и применять к ним программные преобразования.
Компиляторы уже делают это :-} И они действительно хороши в классе задач, которые они решают.
Модели UML с генерацией кода — одна из попыток сделать это. Не очень хорошая попытка; почти то, что говорят в большинстве моделей UML: «У меня есть данные, которые выглядят так». Довольно сложно создать настоящую программу, если не учитывать функциональность.
Я пытаюсь построить практические системы преобразования программ, инструмент под названием DMS. Довольно сильно отвлекся на применение преобразований программы не столько к абстрактным спецификациям для генерации кода, сколько к унаследованному коду для его очистки. (Это те же проблемы в аннотации!). (Чтобы построить такие инструменты, нужно много времени, я занимаюсь этим уже 15 лет, а за это время надо есть).
Но у DMS есть два ключевых свойства, которые я описал выше: способность обрабатывать произвольные формальные спецификации и способность собирать «знания о генерации кода» в виде преобразований и применять их по запросу. И что примечательно, в некоторых особых случаях мы генерируем довольно интересный код из спецификаций; DMS в значительной степени построена с использованием самой себя для создания своей реализации. Это дало нам хотя бы часть обещаний повторного использования (знаний): чрезвычайно значительный прирост производительности. У меня есть команда из 7 технических специалистов; мы написали, вероятно, 1-2 MSLOC «спецификаций» для DMS, но у нас есть около 10 MSLOC сгенерированного кода.
Резюме: повторное использование знаний о генерации — это выигрыш, а не повторное использование кода.
Прикрепляю к посту несколько видео по теме: