Я видел проекты Java, где все интерфейсы извлекаются в отдельный проект.
Какова мотивация для этого? Это просто организационная?
Например, проект атмосферы делает это. Я видел других.
Я рассматриваю возможность использования его в качестве организующего принципа в проекте, который я запускаю, и хотел бы знать, какие другие преимущества он может предоставить.
Существует один прецедент: Java SPI, интерфейс поставщика услуг. Интерфейсы (интерфейсы) предоставляются отдельно, а (альтернативные) реализации поставляются отдельно. По манифестной записи с именем интерфейса, используя интерфейс, вы можете найти всех/любого поставщика этого интерфейса. Идеи Xalan и Xerces XML приходят на ум.
Также без SPI, способного предоставить несколько реализаций, например прототип разработки, управляемый тестированием, может иметь смысл.
Просто чтобы предложить свои 2 цента,
В настоящее время я работаю над проектом С#, у которого есть отдельный проект, содержащий все интерфейсы. Проект был назван "каркасом" и был частью более крупного проекта, включающего 10+ реализаций интерфейсов из этого рамочного проекта. Моя догадка (которая также позже подтверждается моим непосредственным начальником) заключается в том, что она полностью отделяет реализации от дизайна, что называется свободная связь.
Таким образом, различные проекты, которые наследуются от проекта framework, могут быть отдельно разработаны или заменены независимо. От разработчика, нового к проекту, ему легче познакомиться со всеми методами, которые используются в других проектах в одном центральном месте. Добавление новых методов или удаление старых выполняется в одном проекте, и каждый другой проект, который использует эти интерфейсы, имеет строгий "контракт". В сущности он помогает поддерживать проект в долгосрочной перспективе.
Это также упрощает создание макетов определенных частей фреймворка во время тестирования, изолировать каждый класс отдельно и проверить их на возможные ошибки.
Он помогает придерживаться принципа сегрегации интерфейса, в котором, если конкретный интерфейс имеет, например, только метод "save", но нам нужны "журнал" и "чтение" для определенных классов реализации, мы можем просто создать другой интерфейс, который будет наследовать от родительского интерфейса, все в рамках проекта framework, и не пробираться в разных проектах, чтобы найти интерфейс, который мы хотим добавить. Я нашел это, исследуя принцип интерфейса разделения.