Как в определённом классе добавить методы?

Рейтинг: 0Ответов: 2Опубликовано: 24.09.2014

Помогите, пожалуйста, разобраться с архитектурой приложения.
Я пишу маленькую программку, которая работает с базой данных. Я хочу сделать мини-версию того, как в настоящих проектах работает с JDBC, по меньшей мере с точки зрения архитектуры, и возможности легко вносить изменения в уже работающее приложение.
У меня есть общий обобщённый интерфейс с самыми базовыми функциями, такими как: добавить, удалить, обновить и т.д., через который будет происходить работа с таблицами баз данных. Далее имеется абстрактный класс, наследующий от интерфейса, в котором эти самые базовые функции реализованы, ну и добавлена пара абстрактных методов, которые реализуют уже конечные классы.
Сами конечные классы - это менеджеры, которые соответствуют каждой таблице в базе данных.

IManagerDao->AbstractManager->ClientManager  - >MySQL

Теперь сам вопрос: если мне нужно в определённом классе добавить методы (к примеру, в классе AccountManager, который ходит в бд и вытаскивает данные из тaблицы Accounts), то как мне это сделать? Ведь вызывать эти классы рекомендуется через их общий интерфейс:

IManagerDao client = new ClientManager();

Но в таком случае я не буду иметь возможности пользоваться методами класса AccountManager. Как поступают в таких ситуациях?

Ответы

▲ 1Принят

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

▲ 2

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

По вашей иерархии классов: кажется, что она усложнена. По идее, вам достаточно определить интерфейсы DAO (например, ClientDao), а их имплементации для разных БД могут просто лежать в разных пакетах. Абстрактные классы для каждой сущности кажутся лишними.