Каковы негативные последствия включения и/или соединения вещей, которые не используются Вашим двоичным файлом?
Использование дженериков поможет вам начать. TId указывает тип идентификатора.
public class EntityBase
{
public TId Id {get; set;}
}
public interface IRepository
{
Task Insert(EntityBase entity);
bool EntityExists(EntityBase entity);
}
Лично я ненавижу общий репозиторий. Зачем? Это скользкий склон. Я чувствую, что это плохой выбор дизайна. У нас есть приложение с этим повсюду, и это кошмар, чтобы поддерживать. Универсальный репозиторий также не следует принципу разделения .
13 ответов
Некоторые из них, о которых я могу думать, это загрязнение пространства имен и двоичный размер
Возможно, он может даже потерпеть неудачу компилировать, если дерево сборки не в хорошем состоянии. если ваша компиляция на встроенных системах без пространства подкачки. Компилятору может не хватить памяти при попытке скомпилировать массивный объектный файл.
Это недавно произошло с нами.
Если вы связываетесь с двоичными файлами, и они загружаются во время выполнения, они могут выполнять нетривиальную инициализацию, которая может делать все что угодно: выделите небольшой объем памяти для использования ограниченных ресурсов, чтобы изменить состояние вашего модуля так, как вы этого не ожидаете, и даже дальше.
Вам лучше избавиться от ненужных вещей, просто чтобы устранить куча неизвестных.
Я нахожу это разочаровывающим, когда я редактирую файл в дереве исходного кода, потому что какой-то символ, над которым я работаю, появляется в исходный файл (например, имя функции, где я только что изменил прототип - или, к сожалению, но, как правило, просто добавил прототип в заголовок), поэтому мне нужно проверить правильность использования, или компилятор теперь говорит мне использование в этом файле неверно. Итак, я редактирую файл. Тогда я вижу проблему - что делает этот файл? И оказывается, что, хотя код «используется» в продукте, он действительно вообще не используется активно.
Я обнаружил возникновение этой проблемы в понедельник. Файл с 10 000+ строками кода вызывал функцию 'extern void add_remainder (void);' с аргументом 0. Итак, я пошел, чтобы исправить это. Затем я посмотрел на остальную часть кода ... оказалось, что это была заглушка разработки около 15 лет назад, которая никогда не была удалена. Чистое удаление кода оказалось незначительным редактированием более чем полдюжины файлов - и я еще не выяснил, безопасно ли в этом случае удалять константу перечисления из середины перечисления. Временно это помечено как «Неиспользуемый / Устаревший - можно ли его безопасно удалить?».
Этот кусок кода имел нулевое покрытие за последние 15 лет - производство, тестирование, ... Правда, это только крошечная часть огромной системы - в процентном отношении, это менее 1% на графике. Тем не менее, это лишний потраченный впустую код.
Загадочный. Раздражает. Удивительно часто (я зарегистрировал и исправил, по крайней мере, полдюжины подобных ошибок в этом году).
И трата моего времени - и времени других разработчиков.
У меня никогда не было проблем с компоновкой файла .lib, из которого используется только очень небольшая часть. Только исполняемый код будет связан с исполняемым файлом, и время компоновки заметно не увеличилось (с Visual Studio).
Небольшая подборка вопросов, вики-редактируйте ее как обязательно:
Основная проблема, как представляется: Это может вызвать проблемы в будущей отладке, управлении версиями и увеличении будущих затрат на обслуживание.
Также будет, как минимум, незначительное двоичное число , так как будут поддерживаться ссылки на функции / класс / пространство имен (В таблице символов?). Динамические библиотеки не должны сильно увеличивать размер двоичного файла (но они становятся зависимостью для запуска двоичного файла?). Судя по компилятору GNU C, статически связанные библиотеки не должны включаться в окончательный двоичный файл, если на них никогда не ссылаются в исходном коде. (Предположение, основанное на компиляторе C, может потребоваться уточнить / исправить)
Также, в зависимости от природы ваших библиотек, могут создаваться глобальные и статические объекты / переменные, вызывая увеличение времени запуска и нехватку памяти . 1288 Ох, и увеличилось время компиляции / компоновки.
Вы упоминаете об увеличении времени компиляции. Исходя из этого, я понимаю, что библиотеки статически связаны, а не динамически. В этом случае это зависит от того, как компоновщик обрабатывает неиспользуемые функции. Если он игнорирует их, у вас будут в основном проблемы с обслуживанием. Если они будут включены, размер исполняемого файла увеличится. Теперь это более важно, чем место на жестком диске. Большие исполняемые файлы могут работать медленнее из-за проблем с кэшированием. Если активный код и неактивный код смежны в exe, они будут кэшироваться вместе, что делает кэш фактически меньшим и менее эффективным.
VC2005 и выше имеют оптимизацию под названием PGO, которая упорядочивает код в исполняемом файле в способ, который обеспечивает эффективное кэширование кода, который часто используется. Я не знаю, имеет ли g ++ подобную оптимизацию,
Если библиотеки никогда не используются, размер исполняемого файла не должен увеличиваться.
В зависимости от точного компоновщика, вы также можете заметить, что глобальные объекты ваших неиспользуемых библиотек все еще создаются. Это подразумевает нехватку памяти и увеличивает стоимость запуска.
Если библиотеки, которые вы включаете, но не используете, не находятся в целевой системе, он не сможет компилировать, даже если они не нужны.
Здесь - мой ответ на аналогичный вопрос, касающийся C и статических библиотек. Возможно, это будет полезно и вам в контексте C ++.
В дополнение к тому, что перечисляет Саша, стоимость обслуживания . Сможете ли вы легко определить, что используется, а что нет в будущем, когда и если вы решите удалить неиспользуемые вещи?
В дополнение к времени компиляции; Повышенная сложность, ненужное отвлечение внимания при отладке, затраты на обслуживание.
Кроме этого, ничего.