Повторное использование кода
Повторное использование кода (англ. code reuse) — методология проектирования компьютерных и других систем, заключающаяся в том, что система (компьютерная программа, программный модуль) частично либо полностью должна составляться из частей, написанных ранее компонентов и/или частей другой системы, и эти компоненты должны применяться более одного раза (если не в рамках одного проекта, то хотя бы разных). Повторное использование — основная методология, которая применяется для сокращения трудозатрат при разработке сложных систем.
Самый распространённый случай повторного использования кода — библиотеки программ. Библиотеки предоставляют общую достаточно универсальную функциональность, покрывающую избранную предметную область. Примеры: библиотека функций для работы с комплексными числами, библиотека функций для работы с 3D-графикой, библиотека для использования протокола TCP/IP, библиотека для работы с базами данных. Разработчики новой программы могут использовать существующие библиотеки для решения своих задач и не «изобретать велосипеды».
Модульность систем
[править | править код]Программисты стремятся так проектировать свои системы, чтобы они были максимально модульны. В качестве абстракций, на основе которых можно построить модульность системы, могут выступать функции, сопрограмма, класс, протокол. Библиотека функций — хороший пример абстракции, удобной для реализации модульности программ и следования методологии повторного использования. Важным шагом на пути достижения максимальной модульности стал принцип иерархичного построения пространства имён.
Примером удачной реализации модульности и принципа повторного использования могут служить инструменты командной оболочки Unix-систем и стандартные классы Java, помещенные в иерархию пространства имён.
Шаблоны (см. стандартная библиотека шаблонов STL в языке Си++) функций и классов стали важным этапом продвижения методологии повторного использования в индустрию объектно-ориентированного программирования.
Иерархическая модульность системы позволяет реализовать эффективные методы управления разработкой, основанные на построении иерархий управления соответствующей иерархии модулей самой системы.
Повторное использование в малом
[править | править код]Иногда повторное использование кода представляет собой простое копирование некоторой части кода из существующей программы в другую (англ. copy-paste). Это один из самых низкоуровневых подходов к повторному использованию. Но и он имеет место, особенно когда речь идет о повторном использовании кода «в малом» («reuse в малом»).
Подобный подход обычно не рекомендуется к использованию, вместо этого повторяющийся фрагмент программы оформляется в виде подпрограммы или макроса с набором параметров. Основным аргументом в пользу использования подпрограмм вместо копирования кода является то, что в случае наличия ошибки она должна быть исправлена однократно в теле подпрограммы, в противном же случае исправлению необходимо подвергнуть в общем случае несколько идентичных фрагментов кода, расположенных в разных местах программы. Кроме того, при копировании кода обычно возникает необходимость в изменении имен переменных, что также часто приводит к механическим ошибкам. В случае использования подпрограмм подобных переименований можно избежать путём использования локальных переменных.
Повторное использование кода и метасистемный переход в программировании
[править | править код]Метод повторного использования кода является важным компонентом реализации принципа метасистемного перехода в развитии индустрии программного обеспечения. Воплощение этого принципа в жизнь позволяет разработчикам оперировать высокоуровневыми понятиями (отобразить картинку, удалить таблицу из базы данных, найти все корни уравнения, сконвертировать файл и т. д.), а не низкоуровневыми (покрасить пиксел в красный цвет, обнулить регистр, сложить два числа, прочитать символ из файла и т. д.).
Достоинства и недостатки метода повторного использования
[править | править код]Рассмотрим достоинства и недостатки на примере библиотек функций.
Использование готовых библиотек имеет ряд преимуществ. Во-первых, разработчик новой системы снимает с себя заботу о реализации функциональности, заложенной в этой библиотеке. Весь цикл разработки библиотеки осуществляется разработчиком данной библиотеки. Он, обычно, берёт на себя ответственность за поддержку библиотеки: устранение ошибок, развитие и улучшение работы, тестирование. Метод повторного использования кода является тем механизмом, который позволяет разработчикам «встать на плечи гигантов»[1] и быстро строить новые сложные системы из уже отлаженных компонентов. Второе преимущество исходит из самого повторения использования кода, что приводит к существенному уменьшению размера итоговой программы, а при недостаточной производительности носителя и к быстродействию.
Кроме немногочисленных, но очень важных достоинств метод повторного использования кода имеет ряд недостатков. Подключение к проекту сторонних библиотек автоматически приводит к необходимости контроля совместимости версий компонент создаваемой системы и версий используемых библиотек. Самым характерным примером такой ошибки считается авария ракеты-носителя «Ариан-5», вызванная использованием программного модуля, разработанного для ракеты «Ариан-4»[2].
Многие библиотеки коммерческие и требуют денежных затрат (с развитием движения свободного ПО это постепенно теряет актуальность). Кроме того, часто библиотеки недостаточно универсальны и не реализуют той функциональности, которая требуется создаваемой системе, либо, наоборот, слишком универсальны и в результате неэффективны, неудобны или содержат много избыточной (для данного проекта) функциональности. Можно, если позволяет лицензия распространяемой библиотеки, использовать её исходные коды и модифицировать их в соответствии с необходимостью. Но после этого ответственность за поддержку функциональности библиотеки перекладывается на плечи разработчика новой системы. Также использование излишней модульности может привести к уменьшению скорости выполнения программы, когда скорость выполнения, заложенная в модуль, не может перекрыть издержки на обращение к этому модулю.
См. также
[править | править код]- Don’t repeat yourself
- Контрактное программирование
- Процедурное программирование
- Объектно-ориентированное программирование
- Обобщённое программирование
- Метапрограммирование
- Библиотека
- Шаблоны проектирования
Примечания
[править | править код]- ↑ Известное высказывание Исаака Ньютона
- ↑ Jerry Gao, H.-S. J. Tsao, Ye Wu. Testing and Quality Assurance for Component-based Software. — Artech House, 2002. — P. 211. — ISBN 978-1-58053-735-3.
Литература
[править | править код]- Erich Gamma, Richard Helm, Ralph Johnson. Design Patterns: Elements of Reusable Object-Oriented Software. — Pearson Education, 1994. — ISBN 978-0-321-70069-8.
- Johannes Sametinger. Software Engineering with Reusable Components. — Springer Science & Business Media, 1997. — ISBN 978-3-540-62695-4.
- Ali Mili, Sherif Yacoub. Reuse Based Software Engineering: Techniques, Organizations, and Measurement. — Wiley, 2002. — ISBN 978-0-471-39819-6.
Ссылки
[править | править код]- OnceAndOnlyOnce Архивная копия от 29 марта 2014 на Wayback Machine — «один и только один раз», принцип повторного использования, доведённый до крайности.
- Orthogonality and the DRY Principle Архивировано 29 октября 2012 года. — формулировка принципа повторного в контексте принципа ортогональности в проектировании из книги Энди Ханта и Дэйва Томаса «The Pragmatic Programmer».
- Tips for Effective Software Reuse Архивная копия от 23 декабря 2016 на Wayback Machine (англ.) About InfoQ Архивная копия от 23 декабря 2016 на Wayback Machine
В статье есть список источников, но не хватает сносок. |