Как управлять константами в разных языках?

13

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

В настоящее время я делаю это с помощью кода, определяющего константы в каждом языке.

Проблема заключается в обслуживании. Если я добавляю новый код ошибки, мне нужно обновить его в каждой библиотеке вручную. В то время как это хорошо для некоторых, это становится утомительным, если я скажу 5 SDK для обновления. Было бы неплохо иметь хоть один источник правды для них.

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

Есть ли лучший способ обработки констант, которые совместно используются несколькими языками?

enderland
источник
Ваш подход в порядке, enderland. Я пытался найти лучшее решение для переопределения, потому что много раз много клиентов используют API, которые я программирую, и там действительно нет элегантного решения. Переопределение констант по-прежнему является наиболее простым.
Энди
5
@DavidPacker нет, нет, у вас должно быть действительно элегантное решение для меня. Не говори мне, что это лучшее, что есть! :-)
enderland
1
Я подверг сомнению свой выбор, но потом понял, что константы должны быть постоянными. Они предсказуемы, потому что они постоянны. Храня их в формате JSON или любом другом, обычно разбираемом формате, они больше не являются константами. Типичным примером в моем рабочем процессе является объект уведомления, содержащий typeатрибут для идентификации структуры при передаче его по проводам. Имея это, мобильные клиенты определяют только те константы (типы), которые они понимают в данный момент времени, и игнорируют любые неизвестные типы. Динамическое определение вызовет много проблем.
Энди
Вам нужна таблица таблиц, которые отображаются на строки констант из таблиц языков.
джонни

Ответы:

10

Хотя я думаю, что ваш нынешний подход, вероятно, является самым простым и простым, вот пара альтернативных идей:

  • Извлеките ваши константы (и, возможно, модели) в другой пакет, который кросс-компилируется для всех ваших языков. Возможно, вы сможете кросс-компилировать всю библиотеку, но это может привести к значительному количеству проблем. Просто кросс-компиляция констант должна быть достаточно простой, чтобы не было столько проблем. Вы можете опубликовать свой пакет констант и зависеть от него в своих языковых библиотеках. Хэкс, вероятно, может сделать это. Этот подход хорош, потому что у вас все еще будет проверка во время компиляции (для скомпилированных языков)
  • Храните конфигурацию в центральной службе. Например, мыльные веб-службы имеют язык описания веб-служб (WSDL), а службы REST имеют язык описания веб-приложений (WADL), который описывает операции и сообщения службы. Существуют также общие сервисы централизованной конфигурации, такие как Spring Cloud Config.
  • Конфиг файл. Я знаю, что вы уже предложили это, но я не думаю, что это должно сильно усложнить процесс сборки / выпуска. Поместите ваш конфигурационный файл в отдельный проект сборки (где вы можете установить его версию). Опубликуйте проект во всех языковых репозиториях пакетов (Maven, Nuget, NPM и т. Д.), А затем в своих языковых библиотеках вы можете зависеть от пакета. Это не должно быть сложнее, чем иметь дополнительный проект в конвейере сборки.
  • Как предложил RubberDuck, генерация кода является хорошей альтернативой кросс-компиляции. Вы можете генерировать постоянные определения для каждого языка, используя общую конфигурацию.
Самуил
источник
5
Генерирование кода @RubberDuck звучит интересно (особенно для одного из моих тангенциальных вариантов использования, который в любом случае уже включает генератор кода).
enderland
3

Отличный вопрос! У меня точно такая же проблема; мои константы по существу: какие языки поддерживаются в моих приложениях, а также дополнительную информацию об этих языках, поскольку они относятся к функциональности в приложении.

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

Очевидно, что это неправильно, потому что это противоположно СУХОЙ ( ВЛАЖНОЙ ?? ). Однако константы должны меняться так редко, чтобы 5-10 минут переопределения их для каждого языка меня не особо беспокоили. В конце концов, небольшие проблемы с некоторыми «элегантными» решениями, такими как общая конфигурация или генерация кода, могут занять несколько часов или дней, так что же в действительности получается? Сложность и риск того, что что-то пойдет не так, что может потребовать дополнительных усилий, - это не то, с чем я хочу иметь дело.

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

Короче говоря, переопределение их для каждого языка было моим лучшим решением, и мне еще предстоит придумать что-нибудь более СУХОЕ, которое не будет иметь большего фактора риска, чем я хочу иметь дело.

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


Я должен также упомянуть, что за эти годы я видел многоязычные порты различных библиотек (слишком утомленные, чтобы помнить, что они есть в данный момент), написанные одной и той же группой, в которой неизменно определены константы в самих языках. Нет общей конфигурации, нет генерации кода (за исключением клиентских библиотек API Google ... но давай, у Google есть ресурсы, чтобы позволить себе такую ​​сложность). Так что я думаю, что мы натолкнулись на кирпичную стену на этом. Может быть, кто-то в конце концов придумает библиотеку для решения этой проблемы;)

Крис Сирефице
источник
0

Надеемся, что ядро ​​вашей библиотеки написано на одном языке, а другие библиотеки используют FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface ) для вызова основной библиотеки. Это даст вам центральное место для предоставления API для публикации констант и определений из. Таким образом, все внутри библиотеки. Я только упоминаю об этом, поскольку, похоже, он не включен в ответ Самуила.

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

Роберт Барон
источник
1
Hopefully, the core of you library is written in one language, and the other libraries use FFI К сожалению, у нас есть библиотеки как для веб-клиента, так и для серверного кода (на нескольких языках), так что ... это было бы нетривиально (и, возможно, уязвимость безопасности, если бы мы могли начать с веб-приложения).
enderland
Я бы посоветовал вам улучшить вашу безопасность, так как я бы никогда не стал доверять своим пользователям настолько, чтобы сохранять секретность файлов конфигурации.
Роберт Барон
Как вы развертываете веб-приложения, которые обрабатывают коды ошибок? Или имена полей JSON? Меня смущает то, что, по вашему мнению, я делаю, это проблема безопасности. Выполнение произвольного кода на компьютере моего клиента - это абсолютно проблема безопасности, поэтому, похоже, что он не может проанализировать json с сервера, если я что-то упустил.
enderland
Я работал в компаниях, основой безопасности которых были генераторы случайных чисел в стиле DOS и начальные значения, хранящиеся в виде констант. Они, как правило, исправляются очень быстро после того, как на них указывают. Однако, если вы отправите начальное значение миру, вы отдадите ключ к королевству. Поскольку ваше программное обеспечение, по-видимому, в основном основано на веб-технологиях, сохраните конфигурацию в объекте JSON и позвольте каждому языку анализировать одно и то же. общий файл.
Роберт Барон
Имена полей JSON, вероятно, не должны и не должны быть постоянными. Какова вероятность того, что эти имена полей нужно будет изменить, но вы не измените имя самой константы? Вы, вероятно, с большей вероятностью выиграете от генерации кода для доступа к записям или от использования языка выражений, такого как ObjectPath.
Ли Райан