Common, utils, shared Все когда-нибудь сталкивались с пакетами из набора файлов или и того хуже одним файликом с названием utils. Сегодня мы обсудим подобные сущности и их минусы. utils Если подумать об ответственности и необходимости подобных сущностей мы можем заметить, что основной причиной их создания является необходимость обслуживать определённый набор объектов, компонентов и т.п. Например часто под utils прячется некая математика или функции для формата. Минусы данного подхода очевидны. Таким образом вы задаете модель работы вашего когда по средствам вызова методов из определенного набора файлов лежащих в одном пакете. Со временем в utils появляется все больше файлов и в конечном итоге это приводит к свалке. Усложняется процесс тестирования кода и в целом какой-либо ориентации по нему. Utils - стоит рассматривать не как набор компонентов, а как единый компонент или единый объект, который к сожалению очень напоминает GodObject и нарушает все CC принципы. Если все же есть необходимость создавать подобные сущности то делайте их как можно меньше и более явно выделяйте какие задачи они решают. Ваш utils должен выражать задачу которую он решает чётко, а не быть нечто смежным. Кроме того, если вы думаете, что в вашем проекте подобных свалок нет, то вы можете ошибаться. Utils - всего лишь концепция при чем достаточно посредственная. Сейчас стало популярно называть старый добрый utils другими именами, типа shared, utility, services и т.п. common common же решает несколько иную задачу. common - общее для нескольких модулей или компонентов. Например общие протоколы или интерфейсы. Их создавать очень даже стоит дабы это общее выделять и упрощать работу с кодом. При этом следует выполнять такой же принцип, который действует и на utils. common - не должны быть большими и объединять много всего. Например common в корне проекта не очень хорошая практика. В common не должны появляться функции которые использует что-то одно и из этого следует важное правило. common не должен становиться utils!