Framework в Java: правильно ли реализовать реализацию напрямую vs интерфейса?

Question

Я видел несколько ответов на вопрос, должны ли все классы Java реализовывать интерфейсы или нет. Мнения различаются, и лично я не вижу преимущества написания интерфейса, если я уверен, что для него будет только одна реализация.

В этом случае, однако, этот конкретный класс является частью структуры и будет использоваться другими. Уместно ли пользователям напрямую использовать реализацию или я должен создать для нее интерфейс? Сейчас я контролирую доступ пользователей к методам через public/private.

Классы, такие как String, не реализуют интерфейс, и мы используем их напрямую. С другой стороны, этот код довольно старый и, возможно, с тех пор ситуация изменилась, и он не был обновлен, чтобы не сломать что-то.

Answer 1

Прежде всего: это вообще хорошая идея не быть догматичной о ничего.

Подумайте об этом так: когда вы строите дом, вы не должны выбирать один гвоздь, который вы собираетесь использовать, - вы не можете использовать гвозди для всего, и они были специально спроектированы в разных размерах, чтобы вы могли выбрать тип, который наилучшим образом соответствует вашим конкретным потребностям и материалам, когда они вам понадобятся.

Так как и когда использовать интерфейс полностью зависит от типа, структуры и предполагаемого использования вашего класса. Конечно, вам не обязательно будет использовать один интерфейс для каждого класса - особенно если вы не цените SRP и не уменьшаете свои классы и не ограничиваетесь одной ответственностью. Но иногда вы можете это сделать, и иногда вы даже найдете веские причины для внедрения более одного интерфейса в одном классе.

Важная информация о интерфейсах заключается в том, что вы используете их в аннотациях из конкретной реализации, независимо от того, сколько различных реализаций у вас будет. Существует множество возможных причин для этого, например. позволяя кому-то обрабатывать экземпляр для вас (например, сервер приложений, этот подход часто используется для фреймворков, btw), развязывать компоненты для улучшения управления зависимостями, а не забывать модульное тестирование (гораздо проще обмануть объект, когда ваш код имеет только ссылки на интерфейс) и т. д. Это не то, что должно решаться на основе того, сколько раз API будет реализован, но при выборе лучшего способа сохранить ваш код в чисто структурированном, слабо связанном и читаемом.

Чтобы решить, что делать, начните с изучения того, как вы строите дом: ознакомьтесь с SOLID principles и попробуйте применить их хорошо - вы узнаете намного больше об абстракциях и интерфейсах, и что они должны быть используется для. У них также не будет ответа на все, но оттуда вы можете начать делать свои собственные наблюдения и, возможно, изобретать свои собственные принципы, чтобы справиться с тем, что они не покрывают. Они, безусловно, хорошее место для начала.

Answer 2

Если вы контролируете, как создаются экземпляры, то не имеет значения, что вы публикуете. Если вы не контролируете, как создаются экземпляры, то это имеет значение совсем немного.

Клиенты не могут создавать интерфейсы, они могут создавать только конкретные объекты, которые их реализуют.

Однако, если экземпляры всегда создаются с помощью какого-либо механизма, которым вы управляете (фабрика, поиск, инъекция, что угодно), тогда большую часть времени различие между интерфейсом, абстрактным или конкретным классом - вопрос.

Если ожидается, что клиент расширит экземпляр, то это также повлияет. Вы можете расширить интерфейс, но не так, как вы можете расширить обычный класс. Механика и разветвления немного отличаются.

В конце концов, в большинстве случаев конкретный класс может быть преобразован в интерфейс, при этом никто не станет более мудрым, если только они не создают свои собственные экземпляры.