Зачем использовать интерфейс в шаблоне проектирования Dao или другие шаблоны проектирования

См. ниже компоненты шаблона проектирования Dao:

Образ объекта доступа к данным или шаблон DAO используются для разделения доступа к API с низкими уровнями данных или операций с бизнес-сервисами высокого уровня. Ниже приведены участники шаблона объектов доступа к данным.

Интерфейс объекта доступа к данным - этот интерфейс определяет стандартные операции, которые должны выполняться на объектах модели.

Конкретный класс объекта доступа к данным. Этот класс реализует интерфейс выше. Этот класс отвечает за получение данных из источника данных, который может быть базой данных /xml или любым другим механизмом хранения.

Объект модели или объекта значения. Этот объект является простым POJO, содержащим методы get/set для хранения данных, полученных с использованием класса DAO.

Зачем нам нужен ИНТЕРФЕЙС, когда у нас есть конкретный класс, и почему мы не можем использовать его напрямую? Это может быть наивный вопрос, но, пожалуйста, помогите мне понять это. Не только в шаблоне проектирования DAO, но и в других шаблонах проектирования, использование INTERFACE немного запутанно. Я согласен, что это связано с повторяемостью кода и уменьшением сцепления. Но может кто-нибудь объяснить это немного дальше.

ОТВЕТЫ

Ответ 1

Не только в шаблоне проектирования DAO, но и в других шаблонах проектирования INTERFACE немного запутан.

Интерфейсы - одна из лучших в Java. Позвольте мне объяснить это на примере: скажем, вы разработали GPS-устройство для автомобиля, которое смотрит на карту и автоматически превращает автомобиль в направлении, как видно на карте. Это устройство GPS можно использовать во многих автомобилях, таких как benz, fiat и т.д. Для каждого автомобиля механизм поворота влево или вправо может различаться в зависимости от внедрения системы автомобиля. Таким образом, эти функции должны быть написаны автопроизводителем и придать этим методам интерфейс, который реализуется автомобильным изготовлением в соответствии с его реализацией автомобиля. Интерфейс включает только набор функций объявлений, которые должны быть определены изготовителем автомобиля (в этом случае). Понял?

Чтобы узнать больше об интерфейсах и почему они полезны, прочитайте эту статью.

Мой вопрос: зачем нам нужен ИНТЕРФЕЙС, когда у нас есть бетон класс и почему мы не можем использовать его напрямую.

Среди многих других преимуществ, которые были указаны в ответах ниже, вы можете создать много классов DAO для разных структурированных данных (derby db, огромные стеки и т.д.), которые реализуют интерфейс DAO. Преимущество состоит в том, что каждый класс может храниться в переменной интерфейса DAO, называемой polymorphism.

Ответ 2

На самом деле его нет необходимости иметь интерфейс, если у вас есть только одна реализация. Но есть определенная ситуация, когда очень практично, что у вас нет привязанности к конкретному классу:

  • Тестирование вашей службы, которая вызывает DAO: вы можете написать макет DAO который ведет себя так же, как вам нужно в тесте (например, simulat, что там не является соединением DB, которое трудно воспроизвести автоматически)

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

  • Переключение технологии БД. Если вы переключитесь с MySQL на DB2, вы просто необходимо написать еще одну реализацию интерфейса и переключить MySQL DAO и DB2 DAO

Поэтому хорошая практика иметь интерфейс для вас DAO и сервисов.

Ответ 3

Мой вопрос: зачем нам нужен ИНТЕРФЕЙС, когда у нас есть конкретный класс, и почему мы не можем использовать его напрямую.

Это простая абстракция. Предположим, вы используете базу данных Oracle в качестве своей базы данных. Таким образом, конкретный класс будет иметь логику для доступа (CRUD ops) Oracle DB. Завтра, если ваша лицензия истекает, и вы больше не хотите использовать Oracle DB, вместо этого вы захотите использовать MySQL. Теперь вам придется переписать конкретный класс, о котором уже упоминалось, и с этим вам придется переписать слой обслуживания, потому что, используя конкретный класс и его методы, у вас плотная связь между уровнем сервиса и уровнем доступа к данным. Всегда нужно проектировать системы с раздельной связью.

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

Ответ 4

Всегда хороший дизайн для ветки интерфейса от реализации. Он предоставляет больше абстракции и гибкость для вашего кода. Клиентам вашего интерфейса DAO не нужно знать, как он реализован, но только методы, которые он предоставляет.

В конце концов, интерфейсы являются хорошей практикой для обслуживания вашего кода.

Просто добавлю, по моему опыту в Unit Tests через mocks, намного проще создавать макетные объекты, когда объект, который вы издеваетесь, имеет интерфейс. Поэтому использование интерфейсов для меня упрощает выделение и тестирование кода.