В качестве отдельного ответа: эквивалент условной компиляции в Java.
(Возможно, для вас было бы лучше задать это как отдельный вопрос).
Как вы, вероятно, знаете,В Java на самом деле нет условной компиляции, конечно, не в смысле препроцессора C.
В некоторых случаях достаточно просто поместить каждую альтернативу кодирования в блок if
, управляемый константами, ошибаться, static final
полей.Если эти поля можно оценить во время компиляции, чтобы их значения были эффективными константами, то компилятор достаточно умен, чтобы полностью удалить код из if
блоков, которыми он управляет.Однако код внутри этих блоков все еще компилируется (в отличие от препроцессора) и подвергается проверке синтаксиса.Иногда меня раздражает, что #import
, используемые кодом с закомментированными константами, объявляются (в моей Eclipse IDE) неиспользуемыми, но если я пропущу #import
, тогда мое кодирование будет неправильным, если я изменю константы.
Обратите внимание, что эта «константа» может быть определена в отдельном классе, поэтому изменение вашей «конфигурации» может быть достигнуто путем изменения значения в одном файле.
Ещевысокоуровневый ответ на ваш вопрос включает в себя настройку во время выполнения, внедрение зависимостей и тому подобное.Основная идея состоит в том, чтобы ваш системно-зависимый код содержался в отдельных классах (по одному для каждой целевой системы), каждый из которых реализует один и тот же интерфейс (ы).
Во время выполнения приходит около двух разных механизмов.обратите внимание на выбор правильного кода:
Ваш код имеет поле, тип которого является типом общего интерфейса;при запуске ваша программа считывает имя соответствующего класса из файла конфигурации, создает экземпляр объекта этого класса с помощью Class.forName()
или чего-то подобного, назначает этот объект полю и затем использует методы этого экземпляра для выполнения любой конфигурации.необходимо выполнить определенные действия.
Если вы развертываете свою программу в виде Jar
файлов, вы можете создать отдельные файлы Jar, содержащие по одному каждому из ваших классов, зависящих от конфигурации, и когдавы развертываете свою программу, вы развертываете "основной" файл jar и один файл jar с содержимым, зависящим от конфигурации.Затем, когда ваша программа запускается, она может искать в своем classpath любой из классов-кандидатов (возможно, путем проб и ошибок с Class.forName()
), а затем она работает аналогично другому механизму.
РЕДАКТИРОВАТЬ
Думая об этом, я подумал о "мета-ответе дзен-буддизма":
В прожорливой безграничности памяти, занятой JavaПрограмма, зачем беспокоиться о нескольких байтах лишнего кода?Если вы действительно хотите кодировать только два альтернативных подхода к выполнению системно-зависимой команды, то проверяйте, кодируйте и компилируйте отдельные методы для каждого из них:
private void windowsProcess();
private void linuxProcess();
... и затем вызывайте тот, который подходит:
public void independentProcess() {
if (runningOnWindows()) {
windowsProcess();
} else {
linuxProcess();
}
}
... и покончим с этим.
Отдельные банки, разрешение времени выполнения и т. Д. Являются решениями, нацеленными на обмен значительными частями механизма кода, возможно, целыми библиотеками ... еслиэто всего лишь несколько сотен строк или около того, я лично не стал бы беспокоиться о неиспользованном коде в моей программе.Это не похоже на Java - быть привередливым к небольшим или даже средним объемам памяти.Какая память у каждого объекта?16 байт?32