Соглашение важнее конфигурации

Соглашение о конфигурации (также известное как кодирование по соглашению ) — это парадигма проектирования программного обеспечения , используемая программными платформами , которая пытается уменьшить количество решений, которые разработчик, использующий структуру, должен принимать, не теряя при этом гибкости и не повторяясь (DRY ) принципы. ^[1]

Эта концепция была введена Дэвидом Хайнемейером Ханссоном для описания философии Ruby on Rails веб-фреймворка , но она связана с более ранними идеями, такими как концепция «разумных значений по умолчанию » и принцип наименьшего удивления в дизайне пользовательского интерфейса .

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

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

Использование этой фразы в Ruby on Rails особенно сосредоточено на структуре файла проекта и каталогов проекта по умолчанию, что избавляет разработчиков от необходимости писать файлы конфигурации XML , чтобы указать, какие модули должна загружать платформа, что было обычным явлением во многих более ранних платформах.

Недостатки

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

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

Мотивация

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

Например, ранние версии Java-сопоставителя персистентности Hibernate сопоставляли сущности и их поля с базой данных, описывая эти связи в XML-файлах. Большую часть этой информации можно было бы получить путем традиционного сопоставления имен классов с таблицами базы данных с одинаковыми именами , а полей с их столбцами соответственно. Более поздние версии отказались от файла конфигурации XML и вместо этого использовали эти самые соглашения, отклонения от которых можно указать с помощью аннотаций Java (см. спецификацию JavaBeans, ссылку ниже).

Использование

Многие современные фреймворки используют подход, основанный на соглашении, а не на настройке .

Однако эта концепция более старая, она восходит к концепции default , и совсем недавно ее можно обнаружить в корнях библиотек Java . Например, спецификация JavaBeans в значительной степени опирается на него. Процитируем спецификацию JavaBeans 1.01: ^[2]

«Как правило, мы не хотим изобретать огромный класс java.beans.everything, от которого людям придется наследовать. Вместо этого мы хотим, чтобы среда выполнения JavaBeans обеспечивала поведение по умолчанию для «обычных» объектов, но позволяла объектам переопределить заданную часть поведения по умолчанию, унаследовав от некоторого конкретного интерфейса java.beans.something».

См. также

Ссылки

^ Дойл, Керри (11 ноября 2021 г.). «Программирование на Ruby: критический взгляд на плюсы и минусы» . Поиск по архитектуре приложения . Проверено 17 декабря 2021 г.
^ Вс (24 июля 1997 г.). Спецификация JavaBeans. Архивировано 6 апреля 2012 г. на Wayback Machine , раздел 1.4.

Бехле, Майкл; Кирхберг, Пол (2007). «Рубин на рельсах». Программное обеспечение IEEE . 24 (6): 105–108. дои : 10.1109/MS.2007.176 . S2CID 9731264 .
Миллер, Джереми (февраль 2009 г.). «Дизайн для соглашения, а не для конфигурации» . Журнал MSDN . Том. 24, нет. 2 . Проверено 9 марта 2022 г.
Чен, Николас (29 ноября 2006 г.). «Соглашение важнее конфигурации» . Архивировано из оригинала 25 августа 2021 года.

Внешние ссылки

Соглашение о конфигурации в Wayback Machine (архивировано 25 августа 2021 г.)

[1] Дойл, Керри (11 ноября 2021 г.). «Программирование на Ruby: критический взгляд на плюсы и минусы» . Поиск по архитектуре приложения . Проверено 17 декабря 2021 г.

[2] Вс (24 июля 1997 г.). Спецификация JavaBeans. Архивировано 6 апреля 2012 г. на Wayback Machine , раздел 1.4.

[1]

[2]