Сегодня я попытался добавить модуль в мой код, и он использовал другой модуль.Это подразделение использовало еще три.И три из них, которые он использовал, использовали в общей сложности 27 других юнитов.
Поскольку этих юнитов не было в одной папке, мне пришлось настроить путь поиска или добавить еще 27единиц в мой демонстрационный проект, просто чтобы я мог вызвать одну из моих библиотечных функций.
Если вы думаете, что это экстремально, просто попробуйте использовать НЕКОТОРЫЕ из JEDI JCL или JVCL, не используя намного больше.
Это пример такого рода связи, при котором создается ощущение, что пытаться повторно использовать ваш код не стоит.
Я думаю, что для моего следующего проекта вместо монолитного dUnit длямодульные тесты, что все тесты для одного многократно используемого фрагмента кода должны быть встроены в свои собственные исполняемые файлы для каждого класса, который они тестируют, и сконфигурированы так, чтобы явно включать нужные им модули, без каких-либо папок поиска / папок библиотеки, которые могутмодули просто молча будут добавлены в код.Тогда я каждый раз, когда кто-то разбирается, разбивает юнит-тесты, и мы узнаем, что случилось что-то плохое.
В любом случае, как мне кажется, это один из способов гарантировать, что ваш код избегает связывания, и что вы можете написать небольшое или новое приложение и вставить в свой код только кусочки (компоненты, если хотите)что вам нужно, без гигантского череда «ада USE-Clause-зависимости».
То же самое, что и заявление Марьяна о том, что «Единый юнит» - это не тот путь, по которому нужно идти;Зависимости в огромном сервисном подразделении станут бесполезными.Чтобы построить любой проект, который использует этот модуль Utility, вам нужно будет иметь доступ ко всем модулям в его разделе интерфейса и реализации.
Сохраняйте это простым.Держите это отдельно.Сцепление плохое.легко и весело Повторное использование возможно только в том случае, если вы избегаете соединения.