У меня есть ситуация, когда я поддерживаю то, что функционально является одной библиотекой на нескольких языках. Часто между ними есть общие константы (например, ключи имен полей json или коды ошибок).
В настоящее время я делаю это с помощью кода, определяющего константы в каждом языке.
Проблема заключается в обслуживании. Если я добавляю новый код ошибки, мне нужно обновить его в каждой библиотеке вручную. В то время как это хорошо для некоторых, это становится утомительным, если я скажу 5 SDK для обновления. Было бы неплохо иметь хоть один источник правды для них.
Я думал о каком-то конфигурационном файле, но он должен быть включен в каждый развернутый пакет, что усложняет процесс сборки / выпуска.
Есть ли лучший способ обработки констант, которые совместно используются несколькими языками?
type
атрибут для идентификации структуры при передаче его по проводам. Имея это, мобильные клиенты определяют только те константы (типы), которые они понимают в данный момент времени, и игнорируют любые неизвестные типы. Динамическое определение вызовет много проблем.Ответы:
Хотя я думаю, что ваш нынешний подход, вероятно, является самым простым и простым, вот пара альтернативных идей:
источник
Отличный вопрос! У меня точно такая же проблема; мои константы по существу: какие языки поддерживаются в моих приложениях, а также дополнительную информацию об этих языках, поскольку они относятся к функциональности в приложении.
К сожалению, лучшее, что я нашел (как и у вас), - это просто переопределить константы для каждого языка, как вы это делаете в настоящее время (я знаю, вы определенно хотели это услышать ).
Очевидно, что это неправильно, потому что это противоположно СУХОЙ ( ВЛАЖНОЙ ?? ). Однако константы должны меняться так редко, чтобы 5-10 минут переопределения их для каждого языка меня не особо беспокоили. В конце концов, небольшие проблемы с некоторыми «элегантными» решениями, такими как общая конфигурация или генерация кода, могут занять несколько часов или дней, так что же в действительности получается? Сложность и риск того, что что-то пойдет не так, что может потребовать дополнительных усилий, - это не то, с чем я хочу иметь дело.
Кроме того, если ваше приложение имеет так много констант, что их переопределение для каждого языка, когда вы добавляете или изменяете их, занимает значительное время, вы можете просто иметь более значительный запах кода для работы, и в этот момент вы можете захотеть включить к чему-то более сложному.
Короче говоря, переопределение их для каждого языка было моим лучшим решением, и мне еще предстоит придумать что-нибудь более СУХОЕ, которое не будет иметь большего фактора риска, чем я хочу иметь дело.
Одна вещь , чтобы определенно сделать, хотя, чтобы убедиться , что ваши постоянные хорошо документированы в обобщенном (и от языка) способ ( у нас есть компания documentarion репо с спецификации, прочие документы, «чертежной доски» документы и т.д. , где мы храним этот документ). Также убедитесь, что у вас есть механизм для синхронизации их определений. Это примерно такая же большая проблема с подходом дублирования, как и у вас, за исключением небольшого психологического стресса от намеренного дублирования кода. Но, в конце концов, ваши постоянные изменения должны быть очень осознанными и нечастыми , поэтому проблемы с синхронностью должны быть практически нулевыми.
Я должен также упомянуть, что за эти годы я видел многоязычные порты различных библиотек (слишком утомленные, чтобы помнить, что они есть в данный момент), написанные одной и той же группой, в которой неизменно определены константы в самих языках. Нет общей конфигурации, нет генерации кода (за исключением клиентских библиотек API Google ... но давай, у Google есть ресурсы, чтобы позволить себе такую сложность). Так что я думаю, что мы натолкнулись на кирпичную стену на этом. Может быть, кто-то в конце концов придумает библиотеку для решения этой проблемы;)
источник
Надеемся, что ядро вашей библиотеки написано на одном языке, а другие библиотеки используют FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface ) для вызова основной библиотеки. Это даст вам центральное место для предоставления API для публикации констант и определений из. Таким образом, все внутри библиотеки. Я только упоминаю об этом, поскольку, похоже, он не включен в ответ Самуила.
Я думаю, что это действительно зависит от того, насколько способна ваша пользовательская база. Достаточно ли способны справиться с передачей другого файла конфигурации? Могут ли они настроить новый сервис? Для подавляющего большинства пользователей, которых я поддерживал, я хотел бы, чтобы все было автономно - таким образом, пользователям не нужно было бы думать об этом.
источник
Hopefully, the core of you library is written in one language, and the other libraries use FFI
К сожалению, у нас есть библиотеки как для веб-клиента, так и для серверного кода (на нескольких языках), так что ... это было бы нетривиально (и, возможно, уязвимость безопасности, если бы мы могли начать с веб-приложения).